I understand your point, but wouldn't doing what you suggest lead to the problem of maintaining two different code bases? This doesn't seem like a good idea at all.
I think a better approach would be to commit to their new design, and do some sort of A/B testing to hone down the new UI until it replaces the old one.
I don't think reddit will die because of the changes they propose. This is just silly. For starters, there are Google Chrome plugins to make reddit more Facebook feed-like.
I myself like the way reddit works right now and would not like it to change much. That said, Reddit the company has to move towards what will make them money. I don't have this data, but their user base might have changed in the past years. People that really enjoy infinite feeds, for example.
Like kyyd mentioned, fiio [1] is one of the best (if not the best) manufacturer of portable players.
I've heard really good things about a Korean brand called Cowon [2] too. Have my eyes on their Plenue line ATM. Pricey, but it's what I'd expect from high-end audio devices.
I always hear people say how reliable mainframes are.
But if I have a startup that needs to distribute its application among different regions of the world, how does a mainframe help me with that?
It is still a single point of failure.
Has there been any sort of study, comparing commodity hardware and mainframes in this setting?
I'll not argue a single mainframe is more reliable than a commodity server. It should be, given how much they cost.
I am not sure if this true for current hardware, but once upon a time the mainframe CPUs contained duplicates of each functional unit that ran in lock step; after every computational instruction, the results of the units are compared; if they differ, the CPU repeats the instruction once. If the results still differ, it "calls in sick" to the operating system.
The OS then brings a spare CPU online and transfers the program that was running on the failing CPU to the new CPU, takes the failing one offline, and, depending on your service contract with IBM, calls home for a replacement CPU. The program does not even notice something went wrong. The next day an IBM service technician rings your data center's doorbell and replaces the faulty CPU, all without taking the machine offline.
That kind of resiliency and redundancy runs throughout every aspect of the system's design.
If you can afford it, having a mainframe be your single point of failure is not too bad.
This is definitely impressive, but most of it could be done with commodity hardware and open source software. Let's say I have a task queue with objects like (1, 2) and my task is to add them together and push the result in a new task queue - what's preventing me from doing that twice to make sure the end result is correct?
Sure, I have to implement it manually, but at least my screen will no longer covered in vomit because of all the buzzwords.
My point was that a mainframe could be a single point of failure, but it engineered to such a degree of reliability and availability, that this is unlikely to be much of a problem. Plus, you can cluster them, you can even build clusters spanning several data centers.
From a technology standpoint, I think they are amazing machines.
The problem, of course, is that they are ridiculously expensive, which is why "open systems" (often meaning PCs running Windows or Linux, but also proprietary Unix system) have replaced mainframes in many places. In a way, I think it is fair to say that Google did something akin to what you propose. (I am told, that proprietary software for mainframes is actually so ridiculously expensive that the already-ridiculous cost of the hardware is not that much of a concern, actually.)
As for the buzzwords, if you find a place where you are safe from them, send me post card, I might move there, too. ;-)
Also factor in the operational costs with running your own data center and people to keep things running 24x7. Floor space, storage, power, disaster recovery, people = $$$. Companies have moved away from mainframes and the long term costs by migrating to high powered blade servers, vmware, cobol emulation software.
I'm sure these servers still find homes but the computing choices available today make boxes hard to sell IMO.
I don't think the point is feeling completely calm when things are going bad.
For me, at least, one of the points of stoicism is learning how to take a step back and look at the situation through more rational lenses, and then figure out how to deal with it.
Take the situation you mentioned: failing to support for one's family. I think someone who strives to practice stoicism would do something like this:
- What are the reasons I'm failing to provide for my family? Am I spending too much? Is my salary too low? Is the place I live too expensive? Does my family spend too much money?
- Of those reasons, which ones do I have full control of? (This is were you can actually act on).
- Which ones do I have some control of? If your family is the cause of financial distress, there are some actions you can take (like talking to them and explaining things have to change), but you can't fully control their actions and thoughts.
- Which ones do I have no control of? Don't worry about these, there is nothing you can do anyways. But here is the catch, you are eventually going to worry about them. This is what people fail to get about stoicism. It is not a silver bullet that is going to take away all your worries. It is an instrument to help you overcome them, with reason. It takes some practice to get good at it.
I second this. "A Guide to the Good Life" is a fantastic introduction to Stoic principles.
I also read "Stoicism and the Art of Happiness", but did not enjoy it as much. I think Irvine's book is more to the point.
I've found that stoic practices help me in things I would not have thought of: job interviews, for example. Doing negative visualization, imagining interviewers asking me stuff I don't have complete knowledge of, and imagining how I'd respond to it was extremely helpful recently.
> I think multicore capabilities will be here soon.
Just a word of caution to set expectations. The "will be here soon" status has been there for a while, to the extent that it now evokes memories of GNU Hurd, Duke Nukem Forever. It will be ready whenever it will be ready, its in good hands, but don't hold your breath, try to work around it for now.
Multicore is picking up pace, and there will be a paper on the formalised memory model at this year's OCaml Workshop in Oxford in September.
There are a series of milestones to hit: the runtime GC, the memory model, the low-level programming model using one-shot continuations, and how it affects libraries running over it (e.g. algebraic effects). Each of these have associated papers and talks (see the ocamllabs.ionews section), so it's not quite fair to compare it to Duke Nukem Forever :-)
> so it's not quite fair to compare it to Duke Nukem Forever :-)
Apologies if it came out harsh. Oodles of respect for all the work you guys are doing. Its a lot of work and that's why I said things are in good hands.
I second on this. The multicore support is not far away. Right now we have a memory model for multicore OCaml and even a multicore OCaml ARM64 backend.
Not yet (we're working on it)! But it has been an absolute joy to work with rust so far. We haven't had a single crash in production since we started using it and the zero-cost, high level abstractions allow you to write nice, safe APIs with very little code. All that while providing stellar performance and still being able to write low level code when necessary. The ecosystem is still growing and sometimes you have to put in a little more work to get certain functionality that is well supported in other languages because the library/crate for that does not exist yet or is in an early stage of development. Rust also has an amazing community.
We are long-time sponsors of rustfest, so If you are in europe this could be a good opportunity to get to know some of the team members and ask questions.
AFAIK, there's nothing conclusive about supplementing brain functions. Examine.com has a good write up on creatine [1].
I've used creatine with the goal of increasing performance in strength training. I guess I'm a non-responder, 'cause there was no noticeable gains in performance for me.
I think a better approach would be to commit to their new design, and do some sort of A/B testing to hone down the new UI until it replaces the old one.
I don't think reddit will die because of the changes they propose. This is just silly. For starters, there are Google Chrome plugins to make reddit more Facebook feed-like.
I myself like the way reddit works right now and would not like it to change much. That said, Reddit the company has to move towards what will make them money. I don't have this data, but their user base might have changed in the past years. People that really enjoy infinite feeds, for example.