ADM3a was a terminal, not a computer. I used to use these two in around 1976 or so. And the hjkl pattern has nothing to do with this or any other terminal. The ASCII control codes for Ctrl-H, Ctrl-J, Ctrl-K and Ctrl-L were used to make the Teletype's printing carriage move left, down, up or right. Bill Joy's innovation was "modes" so that Ctrl-H did not delete the character when it moved left, etc...
8 H backspace
9 I tab (right a lot)
10 J line feed (down)
11 K vertical tab (down a lot)
12 L form feed (down a page)
13 M carriage return (left a line)
Bill Joy didn't invent modes; all editors were very modeful until Bravo, in the 1970s. And in vi, you don't use ^H to move left; you use h. Tony has already corrected you on ^K and ^L, but I'll point out that there was a way to move the carriage right on a Teletype, even though it wasn't ^L: the SPACE character does that.
Lots of people just like to build things and it is often easier to build a tool than it is to find a pre-existing tool that you can get, you can learn and you can use to solve your problem in less time than building something. All too often when you choose the reuse path, you end up going around in circles with stuff that may be good, but it doesn't fit your problem very well.
Also, humans are builders. It's what we do.
If you look at this problem closely, like I have over the past 15 years or so, you can already see evolution and natural selection happening. So I don't really see diversity as a big problem, and I do expect that in a generation or two, there will be a lot more consensus around which tools to use. However, even then, I do expect to see a fair amount of diversity.
Even today, where Google dominates search, they are dwarfed by Baidu in China. And in Russia, many people prefer Rambler. Orkut is a big social network in Brasil, Vkontakte in Russia, etc. Programming tools and libraries are the same, i.e. a lot of the choices are made for cultural reasons and that will never go away so some diversity will always be here.
Hopefully more people can gain the perspective that many years of experience bring, and can contribute to the process of natural selection (which implies improvement too) in order to get more people choosing and using better tools.
They ARE scaling horizontally. Remember where they mentioned that they are putting StackOverflow, one of several sites that they run, on its own box? That is horizontal scaling. They now have two shards, one with SO and one with all the other sites.
NoSQL is also pretty serious business because what you are doing is deconstructing the relational database and assembling the bits that do the job that you need. A lot of NoSQL tools are marketed as doing far more than they really are capable of and you need real skills and knowledge of database internals to be able to navigate this treacherous area.
That's why you see so many blogs about companies changing core NoSQL technologies.
If you don't get enough interviews in a week of sending out resumes and cover letters, rewrite the resume. Week after week. During interviews you will learn what you forgot to mention, and you should get a sense of what is best left out. Resumes need to be short. They need to sell you as a solution to a company's problems. They need to leave out a lot of details which can be filled in during an interview.
Hone that resume. Try several different versions targeted to different types of jobs. Carefully write your cover letters based on the job ad, and with the intention of getting an interview.
A resume is not an employment history so don't include any more of that than is necessary to be conventional. Leave out the summer jobs in highschool if you are older than 25. Focus on achievements, projects completed. Tell them how you helped your employers over and over again.
And weave lots of technical terms into the text so that it shows up on a keyword search. But do leave out useless keywords like COBOL and VMS.
Don't say your age, and be careful not to inadvertently disclose your age by saying that you worked X years with Y technology which we all know was obsolete in 1995.
VMS and COBOL are still good keywords at my current client. they even offshored COBOL development and trained COBOL developers in the off shore to make sure they still have qualified people supporting and adding to application(s).
That's old fuddy duddy thinking. I'm 56 and I see plenty of people my age that thought like this and they have little to do now other than play golf an wait for dementia to kick in.
I did things differently, started an ISP business in 1994, worked in a Silicon Valley startup for a year, did some consulting in Australia and went to live in Europe. My life was much more interesting than those people who stuck to the daily grind, I reinvented myself (i.e. kept on learning new things every year) a few times, and according to the latest research, I don't need to worry about dementia for a long time. I might not have a nest egg but I have skills in sofware development, systems admin and dba areas that my few of my peers have, and no younger person has. I intend to keep on working and creating new technology until the end of my days, which if my grandparent's lives are an indication, will be well into my 90's.
"That's old fuddy duddy thinking. I'm 56 and I see plenty of people my age that thought like this and they have little to do now other than play golf an wait for dementia to kick in."
I didn't say anything about quitting work. What you do with your time when you're independent is literally up to you. Stay in your same job, stay in your same field, change careers, study, donate your time or muscle, do something that's strictly personally meaningful, play golf (bleah).
This is very true, In fact on the very first day of my first job I spent time figuring out researching retirement options.
Many people laughed, I told them unless a comet is about hit tomorrow, not worrying about tomorrow doesn't make any financial sense. Because tomorrow always comes and in 99% of the cases to 99% of the people. So 'don't worry about tomorrow' is bad financial advice anybody can give you.
I started planning and investing, five years into my work life now. I have done far better than my other friends who even got paid a lot better than me. I am sure another 5 years and a decade into my career I can achieve the kind of financial independence you describe.
And again as you said, retirement doesn't mean not doing any work. It just means you have sufficient backup to support you if you don't have work.
That is because the distribution channel is skimming all the profits. If YC'ers made a new distribution system for content creators it would start with young people fresh from film school doing all the work. But after that takes off you will see the Coppola's of the world doing the math, and shifting their allegiances away from the studios and towards the new world.
Here is a free idea that I tried to get implemented in another country while working for a telecom company that was branching into TV services over their DSL connections.
Simply build a site like YouTube with lots of content to view. But unlike YouTube, this site would be pay per view and 100% of the content would be provided by teams of content creators. No backroom licencing deals.
The end user pays a fixed monthly fee for what they watch. After you watch a show, you must rate it before you get to watch another. That means 100% of viewings are rated. At the end of the month all the shows are ranked according to the ratings, and the portion of the monthly fee that goes to content creators, would be divided according to the rankings.
OK, maybe this is more like Netflix than YouTube. The UI is not as important as the system of acquiring and paying for content which is directly tied to viewer rankings. You would need to have a multiple factor ranking system so that cat videos with shot with a shaky video camera can rank high in entertainment value but low in quality and thus earn less. Also a longer show should earn a bigger share than a 2-minute short.
There are other types of things that would also work for this YC request, but I hope to see this as one of the ones that YC funds.
Yes!!!
The development cycle of software like MongoDB, RabbitMQ and so on, is much faster than that of Debian or any other Linux distro. The Debian package is fine for dabbling or low volume use, but for any serious app, you MUST go direct to the developers and use their latest stable release. That is what they support best on their mailing lists, and that is where most bugs are already fixed.
A lot of software development teams are releasing their own RPM and .DEB Linux binary packages for just that reason, to encourage people to use up to date packages instead of the stale OS distro packages.
In a way, it's rather like security updates. Who would refuse to install security updates because it's not part of the Ubuntu 10.4 LTS release? Almost nobody even thinks of doing that. So why would you use old obsolete releases of mission critical software?
> why would you use old obsolete releases of mission critical software?
"If it ain't broke, don't fix it"
Because it's mission critical, and you can't afford for it to break. Once you hit a certain complexity, upgrades almost always break something:
APIs change. Undefined behavior changes. New bugs are introduced. A feature critical to your app starts performing worse. The above changes break something else you depend on (libraries, proxies, etc.)
Upgrading to a significantly changed version of a mission-critical app/library/language is a lot of work, and is sometimes impossible: many projects couldn't be reasonably ported to Python 3 if they wanted to; a lot of important libraries don't work on Python 3.
This is exactly why bug and security fixes are often backported into old versions. Python 2.5 is still receiving security patches. Apache 1.3 was maintained for years after 2.0 was considered stable.
Yes, especially with a database you can't just pull in new updates and expect them to work. It involves reading the release notes and doing a lot of testing. (much of it is automated)
Equally APIs are backwards compatible, behaviour is defined, bugs are fixed, performance is improved and software becomes more compatible with other software.
For an interesting use of RPATH headers to make portable Linux binaries (and shared libraries) have a look at this script that I used to build Python 2.7.2 and a whole pile of 3rd party libraries https://github.com/wavetossed/pybuild
I think that things like RPATH and LD_PRELOAD are exactly what shared libraries should be doing. The reason for shared libraries in the modern age, is increased flexibility.
