Difference is Sun was providing a "full stack" proprietary product including CPUs running a proprietary ISA, Unix OS, compiler, desktop environment and productivity apps. All that Dell does is assembling standard, commoditized parts and putting a free OS on it. Dell's business is incredibly easy to replicate, while Sun's business is extremely hard to replicate. Of course, Sun's competitive advantage turned into a curse when the components of that vertical integration become uncompetitive both features and price wise vs. the GNU/Linux-on-Intel stack. But regardless, Dell could never replicate the vertical integration Sun had.
> Difference is Sun was providing a "full stack" proprietary product including CPUs running a proprietary ISA, Unix OS, compiler, desktop environment and productivity apps.
Can you get an x86_64 CPU from someone other than Intel or AMD? x86 is much more proprietary than SPARC ever was.
Sun used the non-proprietary Open Firmware (IEEE 1275) for booting (also used by Apple with PowerPC), and SBus (IEEE 1496) for cards before moving to PCI. SCSI and Ethernet/IP were there since forever as well.
The "proprietary" label on Sun, at least when it came to hardware, was always a mystery to me.
Sun used a lot of open parts, but they had absolute control over the platform. Everything in your solution came from Sun or a Sun partner. Fujitsu doing weird stuff with Japanese mainframes was an interesting fact but irrelevant to 99% of Sun's user base.
Intel/AMD combined with EFI or IBM-compatible BIOS? You can get that from anybody. An HP server is basically interchangeable with a Dell.
> SPARC has been licensed to several manufacturers, including Atmel, Bipolar Integrated Technology, Cypress Semiconductor, Fujitsu, Matsushita and Texas Instruments.
Fujitsu was selling Solaris-compatible systems (as were many others). Linux and BSDs also ran on them.
There were a number of x86 makers up until the 1990s or so, but who is left of them? Can you still license x86(_x64) to fab your own CPUs? You can with SPARC:
It wasn't just the chip, it was the whole ecosystem.
Could an every day consumer buy a Sparc motherboard, chip, and build their own system? No. There may have been one or two vendors that did that late in the 90's, but they didn't stick around.
Yes you could do this, from Sun Microelectronics back in the 1990's.
We purchased an Ultra-10 motherboard with 250 MHz Ultrasparc II in 1998/1999, fitted it out with compatible third party SVGA, Ethernet and SCSI adapters and ran Solaris on it. Was our production LDAP, Mail and database server for a small ISP for many years.
I later worked for a systems builder that built and sold Sparc/Ultrasparc systems for government (eg. Hong Kong Mass Transit). We were the only vendor in the Southern Hemisphere doing it. So it wasn't common. But yes you could order parts from Sun Microelectronics and build your own systems, and it became easier use certain standard PC compatible parts once they standardised on PCI. We had shelves full of the older incompatible MBus compatible systems and boards as well.
You kind of proved my point: that's an embedded platform. No consumer is going to be running it. The last link indicates "VxWorks, PikeOS, and RTEMS operating systems available."
I'll give you the benefit of the doubt that you can load a Linux distro on there. You have a couple other problems: there's no ethernet or wifi, and you only have 512 megs of RAM.
> You kind of proved my point: that's an embedded platform. No consumer is going to be running it. The last link indicates "VxWorks, PikeOS, and RTEMS operating systems available."
"Consumers" can be running it just as much as "consumers" could be running Raspberry Pis, which could also be considered 'embedded' by some. SPARC is no less (or more) proprietary than ARM: you can license the ISA, fab a CPU, and sell some kind of hardware stack.
Do you think it would be more or less difficult to get a license from Intel/AMD for x86(_X64) than ARM and/or SPARC so you could fab your own chips?
So you don't think the complete lack of connectivity (video, networking, and storage) is going to be a problem for a normal person? There is absolutely no comparison with a Raspberry Pi. It has all those things and great software support. That Sparc platform is for a satellite!
But yes, you are correct, it's much easier to get a SPARC license.
Dell puts a fair amount of engineering into their servers (as do other main brands like HPE and Lenovo) so it's unfortunate they've lost their roots from the old mail order sales company.
If someone else is paying I'd prefer one of these big OEMs for established firmware lifecycle, spare parts and long gray market availability, shock (shipping) and thermodynamics engineering. If I'm paying, Asus or MiTAC (Tyan) are good enough.
Your sentence is a tacit admission that you don't have a very deep understanding of logistics and integration and what it has taken for Dell to build the deep supply chain they have. Yes, it's a commodity system; that's the point; but it's still leagues better than a Supermicro, right? Think about the difference there and why people still shell out for a Dell instead of a Supermicro or Exxact or plain whitebox hardware. There's a lot to a solid Dell server that you might not realize, from disk controllers to iDRAC....
Really? When I first met Sun machines they were selling 68k-based Sun machines that were better specced than Apple and Amiga and such but left them dependent on Motorola’s architecture that had indirect address and thus no future.
Sure they had an in house chip development ARM team right at the time when RISC economics looked good but CPU architecture had to work harder and harder to beat the memory wall and SPARC was not competitive by 2005 and “Hail Mary” projects like CoolThreads were difficult and expensive but did not deliver for customers.
Hypothetically customers could benefit from that proprietary stuff but they benefit even more from rapid progress is competitive, commodity markets.
When I was working at the library circa 2005 we were thinking about replacing all the Windows computers that patrons used to access the online catalog (and other services) with a web browser with Sun Rays, we probably would have bought a few hundred of them and we would have bought some SPARC servers to back them up.
We could have gotten Netscape to run under Solaris but after a week of effort I wasn't able to get Mozilla to build, so no modern web browser. So no Sun Rays. No servers. DTrace and ZFS were great innovations but without the magic of "can run the software you need to run" they are just Blub. Had Sun done the work to get Mozilla running on their machines and forgotten about DTrace and ZFS people might still be using Solaris... but instead DTrace and ZFS found an audience by supporting... the commodity OS!
(arguably at that time supporting a web browser was the #1, #2 and all the way through #99 task that the Solaris team should have been working on at that time and everything else from Java to Tcl to ZFS was a dangerous distraction... and that's how companies in a position like Sun die)
"When I was working at the library circa 2005 we were thinking about replacing all the Windows computers that patrons used to access the online catalog (and other services)"
why were you thinking of going Sun, as late as 2005? just easier to lock down, like kiosks?
We already had a big investment with Sun for back end systems like the library catalog. We perceived managing a big fleet of desktops as a hassle, it was worse then it is now.
Navier Stokes assumes the fluid is a continuum. The smallest scales that it effectively models [1] are larger than the mean free path of the molecules in the fluid, measured by the Knudsen number [2]. Whenever a phenomenon in the Navier Stokes equations happens in a scale on the order of or smaller than the mean free path, Navier Stokes effectively is unphysical. So, this is a phenomenon in the equation we use to model the fluid, not a physical phenomenon observed in a real fluid.
The question is so daft that I’m not sure it’s worth entertaining it. But sure, I’ll bite - it will result in massive displacement in intellectual workers, without creating (a significant number of) new jobs.
u_j du_i / dx_j - Advection. Kinda like momentum transfer from the motion of the fluid itself. Nonlinear, which makes the N-S equations hard to solve
du_i/dt - Rate of change of velocity. Note that this is in an Eulerian framework so it's not the acceleration of a packet of fluid, rather it's just the change in velocity at a particular location in space
Euler is when you omit some terms. Forcing is when you add some other terms to account for phenomena external to the fluid like gravity or flow through a porous medium like in the article.
MTE is not the only blocker here. Pixel 7 series do not have it and are currently supported by GrapheneOS. There are other concerns regarding things like a proper secure element implementation and timely firmware/binary blob updates.
GrapheneOS requires MTE for any newly added devices. Pixel 6 and Pixel 7 series devices do not meet the current requirements. Pixel 8 and later are the devices meeting the full requirements.
Devices are supported until end-of-life rather than being dropped when they no longer meet the requirements. Pixel 6 is nearly end-of-life and Pixel 7 will be end-of-life in a bit over a year. Both have 5 years of updates from launch as opposed to 7 years for the Pixel 8 and later.
We want to require 7 years of updates for new devices rather than 5 but have left it at 5 to help budget devices meet our requirements.
Right, but still my CarbonOS idea ('degraded' GrapheneOS) is better than /e/, Lineage, Calyx, and stock. By 'degraded' I mean the minimal changes to current GrapheneOS needed to get it working on a given GrapheneOS-unsupported device.
An incomplete port of GrapheneOS to Fairphones will be missing many of the core security features and won't have reasonable security updates. Fairphones are nowhere close to reasonably secure devices.
Most people expect to have decent encryption without a strong passphrase, at least 5 years of security updates and a lot more. Fairphone says they provide updates far longer than they do for many components, and those come with substantial delays. Fairphone 5 and earlier have end-of-life kernels without security support. That's a very bad situation and is widely ignored. The more recent devices are headed to the same situation for the Linux kernel and other components.
Shows how ignorant you are of the dynamics of the region. Iranian regime belong to the Shia sect, and backed Assad in the civil war. Sharaa/Jolani's faction are Sunnis, principally backed by Turkey. Shia and Sunnis generally dislike and often fight each other.
> There’s a short sighted cheering on of the 3rd tier and lower companies offering lower rates, but we’re already seeing them ratchet up the pricing and keep larger models closed after they get market attention.
Sorry, but people are cheering on Chinese companies (of whom your are unduly dismissive with your '3rd rate' comment given how good GLM-5.3, Kimi K3 are) not only because they are more economical, but also because they do not constantly refuse to do legitimate tasks and provide you with the weights for self hosting these models.
I feel like many VC driven companies have completely forgotten how to compete on basic value for product and instead tie themselves into knots with meta-competitiveness games.
"We have the smartest model in the world but our company consistently does stupid things" is not a sustainable business model.
Maybe Anthropic's enterprise sales are going brilliantly, and the rest of us are just pixel dust to them.
Still. Brand perception is a thing, and between rug-pull usage policies, weirding verbedly output quality, and "I'm sorry Dave I can't do that" pushback, Anthropic are clearly having strategy issues.
They would not be so vehemently against it if it did not work. There is a reason E2EE, duress passwords and similar technologies are under such intense assault these days.
Doing that in the middle of the AI bubble would be a huge systemic risk to the US and world economy. Expansion of the US economy is now largely driven by the colossal amount of data centers being built. No one anywhere in the world would invest in risky data centers, LLM company IPOs etc if they could get a 30y 20% bond. Financial institutions like investment banks, hedge funds rely on the AI musical chairs to justify the trillions of commitments on their balance sheets. A Volcker style rate hike would trigger a dash for the exit and cause the collapse of some of these institutions, risking a domino effect rippling through the entire economy.
Plus it'd also massively increase USG deficits since all the debt that's added and rolled over would be financed at that elevated rate. At that point, cuts would amplify the above domino effect (cf. Kalecki Levy equation) reducing tax intake, but no cuts would mean unleashing a debt spiral.
> Google supposedly significantly lowered its participation in the C++ development process, and instead started to work on their own C++ successor language.
Did they decide to keep things as is or rewrite in Rust with LLM assistance in the couple years since this article? Carbon seems to have gone nowhere.
Successor languages usually take a long time. Some of them are made by people who are bad at estimates and will grandly tell you that next year they will have finished the language, but that's just because they actually have no idea. In reality it's typically ballpark ten years.
Most programming languages "go nowhere" in the sense that they never end up used for lots of real world projects - but they can have interesting and useful ideas which inspire future languages.
Google writes a tremendous amount of new code. You can reap a large portion of the benefits by using Rust for new code.
At least as far as public info goes it's still being worked on. The GitHub repo [0] has pretty consistent activity and some recent-ish talks [1], one of which says that they are considering a 0.1 release "early next year".
Go is good enough for many tasks. Google wrote that as a replacement for C++ too. I guess Carbon is intended to be more for systems programming? Go had that intent initially, but soon realized that's not a good fit.
reply