12 ms·
Okay. I was at Amazon too in that time frame, and I don't recall the Sun to Linux transition to be all that big a deal. Amazon was always at that time facing c
by sumanthvepa 6y ago
Okay. I was at Amazon too in that time frame, and I don't recall the Sun to Linux transition to be all that big a deal.
Amazon was always at that time facing challenges on every front, the dot-com bubble breaking etc. There was a large build out of distribution centres around this time that was very expensive.
This was just one more of the challenges they faced. I may not have been senior enough to be privy to all the details, but I don't think this particular migration brought the company to near bankruptcy. That's a stretch.
I think the big migration was the database, and it took time, and Oracle was having some difficulties with running on Linux. But we were already using Linux boxes on our desktops since 1999. Webservers had switched to Linux around 1999. And migrating core code base which mostly C/C++ with Java starting to appear to Linux was mostly a challenge for the infrastructure teams and one of those routine large projects that every company has. I don't recall anybody talking of bankruptcy for this reason.
- geoduck14 6y agoPlease share stories of what early Amazon was like. Did you realize you were building a massive company at the time?
- sumanthvepa 6y agoAmazon was already a public company and pretty big that time. But I don't think people like me realised what big could mean 20 years into the future.
- chihuahua 6y agoI worked there for a few years in the early 2000s and it seemed like such an unremarkable company that wasn't going to go anywhere. The stock was always around $20 and whenever it went up, Bezos usually said something that investors didn't like and drove down the stock price (free shipping, search inside the book, etc). Then there was the Segway deal where I amused myself by checking the orders database to see how many they sold (because the numbers were so small) If you told me back then that the stock was going to $3000 some day, I would have stuck around for longer.
- jsolson 6y agoThis was my feeling in 2010 when I accepted an offer. It was a much bigger company by then, but upon joining it still felt stodgy and like any other big corp. I wonder if it still feels that way if you're there (I left in 2013).
- pram 6y agoIt definitely is, it actually made me look back fondly at my time at Oracle if that says anything lol. The fact that it remains an aspirational job (gotta grind leetcode for FANG!) makes me smirk
- akhilcacharya 6y agoI’m not sure what you mean by this. Can you elaborate?
- icedchai 6y agoIf you knew people who worked at Oracle, it might make more sense...
- dash2 6y ago... this makes me suspect that investors are idiots.
- motoboi 6y agoThis proves that predicting the past is much easier than predicting the future.
- dsr_ 6y agoIt is so much easier to spot things in hindsight. We can all see the evidence that supports the conclusion. Let's take Uber. Their core product is a social media app with mapping, tracking and billing features. It has burnt through an incredible amount of money trying to kill competitors, employing 20,000 or so people directly and claiming that a self-driving electric fleet will someday make them insanely profitable. Market cap is up almost 80% in the last year. Who's the idiot? The investor who believes that Uber will be insanely profitable in N years, or the investor who doesn't want any more exposure to Uber than as part of a whole-market index?
- projektfu 6y agoI remember meeting some Amazon developers at OOPSLA around 2000 and being pretty unimpressed. Like they told me they didn't really know what they were doing there and were just getting out of the office. Then, 2 years later, they started hiring the best, and the rest is history. I think hiring top-quality, motivated engineers doesn't just give you good software, it also provides all the idea generation that you're going to need to enter businesses you never thought about before.
- KMag 6y agoPorting code from SPARC to x86 is much easier than the other way around. Most x86 instructions allow unaligned reads/writes, whereas SPARC will SIGBUS on unaligned access (at least on the processors from the late 1990s). The SPARC memory model is also more lax than x86, so x86 hides more concurrency bugs than x86 does.
- tinalumfoil 6y ago> The SPARC memory model is also more lax than x86, so x86 hides more concurrency bugs than x86 does. I think you mistyped this sentence. Did you mean x86 is more lax, so SPARC hides more concurrency bugs? Am I correct that more concurrency bugs would be hidden in a less lax architecture?
- qwertycrackers 6y agoNo, a strict concurrency model means things are more likely to be consistently sequenced; that is, you'll encounter less actual concurrency artifacts. If this model is made more lax, you might discover that you had UB which the previous model was not exploiting.
- mhh__ 6y agoYou're more likely to luck into the behaviour you want with x86 than a more relaxed memory model. I think the Alpha takes the pip for the latter, but I was only something like 3 months old when the IP was sold to Intel let alone in widespread use, so I could be wrong.
- KMag 6y agoYes, the DEC Alpha AXP was a beast of a chip family. The Alpha design team made nearly as few guarantees as possible in order to leave nearly as much room for optimization as possible. The Alpha's lax memory model provided the least-common denominator upon which the Java memory model is based. A stronger Java memory model would have forced a JVM on the Alpha to use a lot more atomic operations. All processors (or at least all processors I'm aware of) will make a core observe its own writes in the order they appear in the machine code. That is, a core by itself will be unable to determine if the processor performs out-of-order memory operations. If the machine code says Core A makes writes A0 and then A1, it will always appear to Core A that A0 happened before A1. As far as I know, all processors also ensure that all processors will agree to a single globally consistent observed ordering of all atomic reads and atomic writes. (I can't imagine what atomic reads and writes would even mean if they didn't at least mean this.) On top of the basic minimum guarantees, x86 and x86_64 (as well as some SPARC implementations, etc.) have a Total Store Ordering memory model: if Core A makes write A0 followed by A1, and Core B makes write B0 followed by B1, the two cores may disagree about whether A0 or B0 happened first, but whey will always agree that A0 happened before A1 and B0 before B1, even if none of the writes are atomic. In a more relaxed memory model like the SPARC specification or Aarch64 specification (and I think RISC-V), if the machine code says Core A makes write A0 before A1, Core B might see A1, but not yet see A0, unless A0 was an atomic write. If Core B can see a given atomic write from Core A, it's also guaranteed that Core B can see all writes (atomic and non-atomic) that Core A thinks it made before that atomic write. With the DEC Alpha, the hardware designers left themselves almost the maximum amount of flexibility that made any semantic sense: if Core B makes an atomic read, then that read (and any reads coming after it in machine code order) is guaranteed to see the latest atomic write from Core A, and all writes that came before that atomic write in machine code order. On the Alpha, you can think of it as all of the cores having unordered output buffers and unordered input buffers, where atomic writes flush the core's output buffer and atomic reads flush the input buffer. All other guarantees are off. (Note that even under this very lax memory model, as long as a mutex acquisition involves an atomic read and an atomic write, and a mutex release involves an atomic write, you'll still get correct behavior if you protect all reads and writes of shared mutable state with mutexes. A reader's atomic read in mutex acquisition guarantees that all reads while holding the mutex will see all writes made before another thread released the mutex.) This might be slightly wrong, but it's roughly what I remember of the Alpha memory model. The thing that confused some programmers with the Alpha is that with most memory models, if one thread makes a ton of atomic writes, and another thread makes a ton of non-atomic reads, the reading thread will still never see the writes in a different order than what the writer thought it wrote. There's no such guarantee on Alpha. On a side note, the Alpha team was also pretty brutal about only allowing instructions that were easy for compilers to generate and showed a performance improvement in simulations on some meaningful benchmark. The first generation of the Alphas didn't even have single-byte loads or stores and relied on compilers to perform single-byte operations by bit manipulation on 32-bit and 64-bit loads and stores. Many of the Alpha design people went on to the AMD K6 III (first AMD chips to give Intel a run for their money in the desktop gaming market), the PASemi PWRFicient (acqui-hired by Apple to start their A-series / Apple Silicon team), AMD Ryzen, etc.) When I bought my first computer in the fall of 1997, the fastest Intel desktop processors were 300 MHz PIIs. DEC Alphas at the time were running at 500 MHz, and had more instructions per clock, particularly in the floating point unit. The Cray T3E supercomputer used DEC Alphas for good reason.
- sumanthvepa 6y agoThe big problem with Linux at the time was large files, and memory addressing limitations of 32bit architectures. x86_64 was still too new and only introduced in 1999. There were other issues as well, that in the intervening 20 years have been more than addressed. Today's Linux is of course far superior to any OS that existed at the time.
- Jtsummers 6y agoThe first AMD64 processor was the Opteron released in 2003, 4 years after the announcement.
- iso1210 6y agoOP might have been thinking of Itanium (ia-64), a different 64 bit PC architecture from Intel. It was shockingly expensive There was certainly development on ia64 in the kernel in 1999 under Project Trillian [1][2], although the first chip wasn't released commercially until 2001 Alternatively they may have been thinking about PAE, which was released in 1999 and allowed linux kernels to address upto 64GB on a 32 bit processor [2] [1] https://lkml.org/lkml/1999/3/9/48 https://lkml.org/lkml/1999/3/9/48 [2] https://en.wikipedia.org/wiki/Project_Trillian https://en.wikipedia.org/wiki/Project_Trillian [2] https://en.wikipedia.org/wiki/Physical_Address_Extension#History https://en.wikipedia.org/wiki/Physical_Address_Extension#His...
- projektfu 6y agoPAE was also used for Microsoft Windows 2000 Server Datacenter Edition. Server machines at the time capable of holding 64GB RAM were beasts, IIRC on the order of hundreds of thousands of dollars. A desktop machine with 512MB memory was considered way more than you needed. I used a Toshiba Tecra 9000 laptop with 256GB for mostly Java and C++ development and never felt like I was anywhere near maxing it out. PAE might not have met Amazon's needs for holding their catalog or whatever. If they were trying to directly address a data structure that was larger than 4GB, they would have needed some sort of trickery as PAE was usually implemented kernel side to provide separate 4GB address spaces to individual processes with more than 4GB total physical backing.
- icedchai 6y agoI remember early versions of Java not running terribly well on Linux. It ran, but performance was bad. I'm thinking the 1.2 and 1.3 versions. I worked for a startup and did some Java and Oracle work around that time, moving apps from Sun to Linux based demo systems.
- bartread 6y agoCan confirm. Around 2000 - 2001, on RedHat 6 or 7.something Sun's 1.2 JVM was basically unusable: slow and extremely buggy. IBM's JVM (HotJava? - it's all so long ago I can't remember what it was called) was much better: it was a bit faster and it didn't fall over for a pasttime. The 1.3 releases were better but still not much to shout about. I can't remember whether the 1.3 Sun JVMs were good enough to allow us to run our software with them at the time. (Topically, at around this time, we were targeting Solaris 6.x and 7.x based systems.)
- beagle3 6y agoTo add: this is Red Hat Linux 6 or 7, not Red Hat Enterprise Linux - I fondly remember RHL 7.3 in 2002 as the last RedHat I liked; updates were still through RHN or Red Carpet (don’t remember if yum was already used). RHEL, Fedora etc arrived later.
- bartread 6y agoYes, exactly, when RedHat was still RedHat as it were: I haven't used either Fedora or RHEL since that division took place. Tbh that's more about circumstance than coming at it with any particular axe to grind but, these days, I can't see much of a reason to choose either of them over Ubuntu. Not for the projects I'm involved with, anyway.
- _old_dude_ 6y agoJava on Linux was interpreted until 1.3.1/1.4 when the VM, named ExactVM, was replaced by HotSpot which includes a JIT. At that time, I remember deciding to prototype a B2B store in Java and then rewrite it in C++ when i will know what i was doing. I never rewrite that soft because Java becomes fast enough overnight. In a sense, SUN kill itself with Java.
- zorked 6y agoThat series of posts should be seen in the context of someone who was working on a Solaris to Linux migration (like EVERY company at the time) trying to claim credit for creating cloud computing. This is NOT the origin story for EC2, which started as a skunkworks project in Cape Town.
- 0df8dkdf 6y agoreally? So EC2 is a DARPA program? Would make sense as Internal is also a military project. EDIT: can you provide some links thanks to this. Thanks.
- oli5679 6y agoBelow is a link with some of the history of EC2. It wasn't linked to Darpa but it was developed as an experimental project by an autonomous team in South African office lead by Chris Pinkham and initially Amazon were quite secretive about it. """The designation "skunk works" or "skunkworks" is widely used in business, engineering, and technical fields to describe a group within an organization given a high degree of autonomy and unhampered by bureaucracy, with the task of working on advanced or secret projects. """ https://www.zdnet.com/article/how-amazon-exposed-its-guts-the-history-of-awss-ec2/ https://www.zdnet.com/article/how-amazon-exposed-its-guts-th... https://en.wikipedia.org/wiki/Skunk_Works#:~:text=The%20designation%20%22skunk%20works%22%20or,on%20advanced%20or%20secret%20projects https://en.wikipedia.org/wiki/Skunk_Works#:~:text=The%20desi....
- iso1210 6y agoWikipedia says Amazon EC2 was developed mostly by a team in Cape Town, South Africa led by Chris Pinkham. Pinkham provided the initial architecture guidance for EC2 and then built the team and led the development of the project along with Willem van Biljon. with links to a Register piece https://www.theregister.com/2010/06/25/nimbula_cloud_os/ https://www.theregister.com/2010/06/25/nimbula_cloud_os/ And https://web.archive.org/web/20100621120705/http://itknowledgeexchange.techtarget.com/cloud-computing/2010/06/17/amazons-early-efforts-at-cloud-computing-partly-accidental https://web.archive.org/web/20100621120705/http://itknowledg...
- 6y ago