ChromeOS will soon be developed on large portions of the Android stack
blog.chromium.org
blog.chromium.org
https://source.android.com/docs/core/architecture/kernel/gen...
Unless something drastic changes, I'm sticking with Apple because of their demonstrated long-term support. Every phone since 2015 has been supported for 6-7 years. And that's actual support, not a "technically correct" mix of real support and security patches only.
https://www.statista.com/chart/5824/ios-iphone-compatibility...
they are using the long life Qualcomm parts, that only guarantee production and stock for x years. maybe with software updates by an intern.
it definitely will not guarantee a new driver set compiling to a recent kernel if the old kernel must be upgraded for security or anything else.
so it's kinda bold they promise that with out any disclaimer that they are just hopeful
> (a)
> The latest available version of the firmware shall be made available for a minimum period of eight years after the placing on the market of the last unit of a certain product model, free of charge or at a fair, transparent and non-discriminatory cost. The latest available security update to the firmware shall be made available until at least eight years after the placing on the market of the last product of a certain product model, free of charge.
(b)
> Information on the minimum guaranteed availability of software and firmware updates, availability of spare parts and product support shall be indicated in the product information sheet as from Annex V of Regulation (EU) 2019/2013.
https://eur-lex.europa.eu/eli/reg/2019/2021/oj
I can't find all of it, but part of it (Samsung also did the same thing) is triggered by EU environment protection directives.
It's really silicon manufacturer's fault for not wanting to mainline and long-term support their BSP, not Google's.
Isn't this what capitalism loving companies say, anyway?
Broadcom had to open source their wireless drivers at the end. Same can happen for SoCs too. Add pressure, if not broken, goto 10.
Also the type of updates guaranteed for 10 years on ChromeOS are not the feature update type that require upgrading the actual OS, just security and bugfix patches.
The Shield was released in May 2015 and its latest software update has an Android security patch level of April 2022 and was released November 2022. No more updates seem to be forthcoming. Notably, all Shield TVs today are vulnerable to remote code execution when displaying a malicious WebP image [0], a widespread issue uncovered last year.
Apple released the Apple TV HD two months after the Shield TV, but it still receives the latest tvOS updates to this day and will be receiving this year's new tvOS 18 [1] [2]. It received a fix for that WebP issue the same day as supported Macs, iPhones and iPads did last September.
Even the best Android device examples with good vendor support still seem to be falling short. The Shield TV is still capable streaming hardware in 2024 used by many people, but it's sitting there doing that while missing important security patches unbeknownst to the users.
[0]: https://blog.isosceles.com/the-webp-0day/
[1]: https://www.macrumors.com/2024/06/10/tvos-18-compatible-appl...
[2]: To be fair it's the only Apple A8 device that receives support until today. The iPhone 6 with the same chip was launched mid 2014 and received its last update in early 2023.
I was thinking of getting a second Shield for my second TV but it turned out I had a $50 PC sitting around which works fine as a media player.
If you're talking about something like Ubuntu, there's a tonne of work that goes into making sure it works with ..say.. a random three year old laptop with all the binary blobs in place.
Try getting something like wifi or Bluetooth working on some weird ARM dev board and suddenly there's no vanilla Linux unless you're willing to write device drivers.
1. Originally you had to use the proprietary binary driver to get anything useful to happen with your card at all. Updating the kernel without updating this would more or less lead to having an expensive brick in your PC. Some Wi-Fi adapters fall into the "can't really be updated" category as well. A _LOT_ of ARM shit is like this.
2. nvidia-open came along (still beta for desktop cards at the moment) and it puts enough in the kernel that you can update the kernel without needing an updated binary driver for your card to function
3. nouveau/nvk have very recently started to come to a decently usable state (i.e. they have reclocking via GSP and somewhat usable graphics API coverage/efficiency) for an even more open driver stack which tracks system updates even better.
If your binary blobs fall into 1/2 then long term upgrades can be anywhere from impossible to unreliable. If they fall into 2/3 they can be anywhere from somewhat reliable to "will be working longer than any sane person would still be trying to update the kernel on that device". E.g. the AMD 7750 is 12 years old but can run OpenGL 4.6 and Vulkan via the latest AMDGPU driver in mainline mesa/kernel.
LTS distros solve this by using LTS kernels and security patching them rather than requiring "actual" underlying OS updates during the version lifecycle.
Android GKI/KMI addresses the issues related to this. GKI is relatively recent and OEMs don't offer 5+ years of Android updates because they haven't adopted it yet.
I think that at least open source community should move to "never break things" concept. So that you can write and test code once and never touch it anymore. Refactoring your code because kernel/library has changed its interface is just a waste of time which gives nothing in return, often time of unpaid volunteers who could do something useful instead.
This should apply to libraries, applications, programming languages, browser extensions. Take upgrading your Python 2 code to Python 3 as an example. You need to put a lot of efforts while gaining nothing. This is not how software should work. You should write a code once and it should work forever without any maintainance.
So if you open source your drivers and get them accepted into the kernel, then you don't need to rewrite/recompile them for each new kernel version. Just like AMD did with their drivers. And I think this is part a conscious decision that forces people to open source drivers.
But this is honestly just guesswork based on what I've read, would love to learn more!
You don't, but someone does. In the note linked above they give an example of how the USB interface changed from synchronous to asynchronous, this must have required some refactoring in all drivers that used USB
[1] http://kroah.com/log/blog/2018/02/05/linux-kernel-release-mo...
no, they do it for you for free - you just have to make sure the quality is high enough to merge into mainline.
as a user, I hate apps that aren't in the repository. it takes effort to make sure it doesn't clobber something important just because the developer wanted to use the latest and most broken version of some library. thankfully nixos allows me to run whatever version of every dependency and then nuke the whole mess once I'm done with it.
That's not going to be fixed. This is a typical M-N problem. There are too many distros and it would require lot of work to port every app to every distro. Instead, there should be a "platform" (set of APIs) that app can work with and the same app would be able to work in any compatible distro.
Just the python's 3 string/binary distinction and explicit conversion squashed an entire category of bugs. Yes, it required to make explicit what was implicit before, but still, that's huge achievement in my book; saying that it is nothing is a very, very shortsighted.
And created an entire category of new ones.
They wouldn't have to, that would be done for them, for free, if they got their code into the kernel...
Once you mainline it, making improvements, supporting new devices and features become 10x slower.
With a stable ABI, it would be better than everything. But we can't have it because of ideological reasons.
That's how you can use a random 25 year old peripheral on multiple versions of Windows without anyone having to update a driver.
For windows you can usually download a binary from some 20 year old website and it'll work.
Avoiding that mess for some notion of beauty or purity only gets you so far.
But that work gets done and "users" of Ubuntu or Debian or Arch get to use it from the sources they trust (aka Ubuntu, Debian or Arch). I'm not claiming to have a full understanding of how every package or kernel module Debian or Arch or Fedora ships works. But I'm trusting Debian or Arch or Fedora for my packages. If it comes to light that debian or fedora maintainers had no idea that they shipped a malware in a release, then I'll seriously question going with that distribution in the future. And without sounding facetious, that has happened multiple times in past especially with debian. But the times it happened it was clear to me that it was merely a mistake rather than extreme incompetence or malice.
With Android, you have Google, which despite the general HN rhetoric I personally trust to not ship straight up malware. But when we're talking about Android that's not what we're talking about. We're often talking about binary ROM blobs from random XDA or RW users. Funny thing is 20 years ago, I'd have shouted about what's the difference between a random anon on XDA or WZBB providing a ROM blob. But now I know better.
Binary blobs are an unfortunate reality and no amount of trust in a company or entity can really solve this.
For the record, Debian and Arch doesn't work very well on non standard hardware. I use arch on my desktop but gave up on using it productively on a new HP laptop.
I understand your usage of the word, I'm just pointing out that if the mainstream ain't "standard" anymore... it kind of sets the standard in practice.
depends; but may i suggest starting at kernel.org then look at 'linux from scratch'/gentoo then maybe slackware; surely not ubuntu
- Vanilla Linux it's propietary.
- GNU/Linux-Libre it's the proper libre one, rebased from GNU maintainers.
- There's no proper 'Vanilla distro' as LFS or Gentoo. Every one since 1993 has been an external bundle made from volunteers.
- The closest vanilla distro from the GNU project would be Guix as it works as a distro and a universal package manager to ship libre software.
There's a reason all other kenels have adopted a stable driver API and ABI.
hardware is either supported or not.
the "work" you mention on old wifi cards is to get a driver that was never contributed in any official way. hence unsupported.
Linux have more hardware support out of the box than anything, ever.
just educate yourself before purchasing.
This reminds me of certain countries that define literacy as the ability to sign ones name.
Linux driver support for a large fraction of hardware is incomplete at best.
They accept only code which they will be able to maintain, yes. That excludes spaghetty or implementations of complex undocumented APIs that are useless without a binary blob. Nothing unreasonable about that.
no sympathy. you're also out of luck using old hardware in the first place because the manufacturer wants you to buy the new version. they will help you LESS than Linux devs. you're point is very unhelpful to the discussion, unless you got drivers updates from the manufacturer
The manufacturer probably doesn't exist any more. They wrote decent drivers and supported them for a number of years, that should be enough. Or maybe a dedicated fan wrote some OSS drivers at some point in the past. On both Windows and FreeBSD that's good enough; once a driver has been written, it largely stays working, so I can keep using my hardware. This really is a unique downside of Linux.
To my understand in Linux most drivers are codeveloped with the kernel as it does not have a stable interface for drivers (one might say that it is a pro as it discourages proprietary drivers)
Samsung offers 7 years of major version upgrades on their flagship lineup starting with the S24. It is not retraoctive, although their 5 year policy has been in place for 2021 devices.
It's unlikely that they will offer security patches beyond that point and the mid-range segment still only gets 4/5 years.
Chinese OEMs offer "major" upgrades for longer, however they achieve this by backporting both Android mainline and proprietary features to older versions of Android, along with security patches.
the solution is to get everyone on the same kernel, which is then updatable - not hack together something that kinda works on top of a never updated snowflake
You keep the binaries, you get to maintain them and solve their problems. Seems fair.
If they are using 3rd party IP, they should work with the providers for compromises, or license the patents and re-implement them.
AMD and Intel did great strides on these fronts, not counting the money-loving people called HDMI forum.
A run-of-the-mill Android or iOS device carries more secrets inside, which have much more weight (biometric data, TOTP, serial numbers used as secure tokens/unique identifiers, etc). This situation makes them a "trusted security device," and allowing tampering with it opens an unpleasant can of worms. For example, during my short Android stint, I found out that no custom ROM can talk with the secure element in my SIM, and I'm locked out of my e-signature, which is not pleasant.
If manufacturers can find a good way to make these secure elements trustworthy without the need to close down the platform and weld shut, I think we can work around graphics and Wi-Fi drivers.
Of course, we also have the "radio security" problem. Still, I think it can be solved by moving the wireless radio to an independent IP block inside the processor with a dedicated postbox and firmware system. While I'd love to have completely open radio firmware, the wireless world is much more complex (I'm a newbie HAM operator, so I have some slight ideas).
So, the reasons for closing down a mobile device are varied, but the list indeed contains the desire for more money. If one of the hardware manufacturers decides to spend the money and pull the trigger (like AMD did with its HDMI/HDCP block), we can have secure systems that do not need locking down. Still, I'm not holding my breath, because while Apple loves to leave doors for tinkerers on their laptops, iPhone is their Fort Knox. On the other hand, I don't have the slightest confidence in the company called Broadcom to do the right thing.
Regarding this:
> Still, I'm not holding my breath, because while Apple loves to leave doors for tinkerers on their laptops, iPhone is their Fort Knox.
People don't realize, but 99% of what Apple does hinges on the iPhone. The rest of the products pack a much lower punch if the iPhone were to vanish from the face of the Earth completely. It's the product all their customers have and they have it at all times with them. It's the product that's probably the easiest to use and the easiest to connect to other things.
So yeah, the iPhone will probably be the last non-military device on the planet to be opened up :-)
By market cap, nvidia is the 3rd biggest one, about as big as google and facebook together. Market cap is a sensible metric.
If you conflate value with size, both terms become near useless. Value can only mean something in relation to something else.
Picture this: You have a large company with thousands of employees having similar revenue to their competitor, which accomplishes the same with one employee and a much smaller operation.
Which one is likely to be more valuable? Obviously the smaller one. If we however conflate value with size, as is so often done in popular economics, just pointing out this single fact becomes a complicated exercise of having to carefully employ language that we neutered for no good reason at all. Not to speak of all the misunderstandings this is going to create with people who aren't used to this imprecise use of the English language.
If you mean revenue, say revenue, if you mean value, say value, if you mean size, say size. Don't use "large" to say "valuable". Why would you do that if there's a perfectly good word already? Imprecise language is often used to either confuse or leave open an avenue to cover one's ass later... which brings us back to popular economics.
Precision is always helpful, but valuation is a very common size metric, and there was no confusion about OP's meaning.
You're going to have to expand that a little bit.
> valuation is a very common size metric
It's not a size metric.
A world where things grow larger the more people value them might be interesting though.
> and there was no confusion about OP's meaning.
Their comment makes much less sense if you replace "biggest" with "most valuable". It's trivially obvious that the correlation between valuation and how much a company can invest into software is incredibly weak if it exists at all. On software development spending NVidia is eclipsed by many companies with sometimes only a fraction of its valuation.
So either it's a non sequitur or we are incorrectly assuming that Nvidia became the largest company.
Do you personally grow larger when you have more money in the bank? When more of your friends get elected in the senate? When you hire someone? When you buy a new house?
OP said "biggest", and meant "largest valuation". This happens to be incorrect -- nVidia was never the highest-valued public company -- but they were the second-largest, and came very close to first.
If you did not know what OP meant immediately from awareness of business news, you still should have considered "valuation" as one of the obvious possibilities. If you did not, then you might be lacking adequate context for this conversation, and might be better served by asking questions instead of demonstrating your confusion via misplaced pedantry.
Size is not a metric. You can measure size with a metric and you can measure value with another metric. Measuring both the same way only leads to nonsense. I think we're getting to the bottom of the confusion now.
> misplaced pedantry
Pedantry is the easiest way of dismantling comments that try to turn nonsense into an argument by being intentionally vague. Should you argue directly against vague statements, the speaker can retroactively make them mean whatever they want to. You'll be chasing moving goalposts. Employ pedantry until they well and truly nail themselves down, and then explain why whatever is left is nonsense. Worked like a charm.
Also, to get ahead of any further personal attacks, this pedantry absolutely is fun to me. I wouldn't be here otherwise.
You are simply wrong. Being condescending and wrong is a fatal mix.
Size is a unitless dimension. A category of metrics, if you must. OP's word of "bigger" can be applied to population, area, weight, importance, memorability, and yes, valuation.
Can be, and frequently is, among humans. Zero humans are confused.
> Pedantry is the easiest way of
... demonstrating that you're a jerk. Nothing else.
> this pedantry absolutely is fun to me
Got it. My mistake for assuming good faith.
> I wouldn't be here otherwise
That's the most disappointing thing I've read in a while.
Just make size a category of dimensions and I'd underwrite that. It certainly doesn't refer to a single dimension.
Mathematically valuation would absolutely be a size/magnitude, but we're clearly not speaking in mathematical terms, given how the terminology is being abused. Mathematically plenty of things that are a magnitude/size do not constitute a metric space, and the singular would be wrong anyways.
I'm taking metric to mean "standard of measurement", which is why size is still not a metric. Saying "size is a category of metrics" would be getting close enough I suppose, but really we're talking about the actual dimensions.
Now that we've got that out of the way, I'm still firmly grouping valuation as a measurement of value, and not a measurement of size. I'm also standing by the assertion that not having these two be disjoint sets only leads to confusion and nonsense.
> OP's word of "bigger" can be applied to population, area, weight, importance, memorability, and yes, valuation.
Nice try. They applied it to "company". You can do that, but now we're not talking about a company's value. We have the adjective valuable for that.
nVidia is also finally moving to an open source kernel module so a closed source one doesn't seem important to them for keeping their moat.
CUDA is much more accessible/documented/available than a lot of comparable products. FPGAs were even more closed, more expensive and had much worse documentation. Things like compute clusters were call-for-pricing, prepare to spend as much as a small house.
On the other hand, CUDA is closed enough the chips that run it aren't a commodity. If you want to download that existing ML project and run it on your AMD card - someone will have to do the leg work to port it.
That means they've been able to invest quite a lot of $$$ into CUDA, knowing the spending gets them a competitive advantage.
Their Windows drivers are a black box which doesn't conform to many of the standards, or behave the way they see fit, esp. about memory management and data transfers. GameWorks library actively sabotaged AMD cards (not unlike Intel's infamous compiler saga). Many nVidia optimized games either ran on completely unoptimized or outright AMD/ATI hostile code-paths. e.g.: GTA3 ran silky smooth on an nVidia Geforce MX400 (bottom of the barrel card) while thrice powerful ATI cards stuttered. Only a handful of studios (kudos to Valve) optimized engines for both and showed that a "paltry" 9600XT can do HDR@60FPS.
On Datacenter front, they actively undermined OpenCL and other engine by aritifically performance-capping them (you can use only one DMA controller in Tesla cards, which actually have three DMA engines), slowing down memory transfers and removing ability to stream in/out of the card. They "supported" versions of OpenCL, but made it impossible to compile on their hardware, except OpenCL 1.1.
On driver front, they have a signed firmware mechanism, and they provide a seriously limited firmware to nouveau just to enable their hardware. You can't use any advanced features of their cards, because the full-capability firmware refuses to work with nouveau. Also, they re not opening their kernel module. Secret sauce is moving to firmware, leaving an open interfacing module. CUDA, GL and everything is closed source.
On the other hand, they actively said that "The docs of the cards are in the open. We neither help, nor sabotage nouveau driver project. They're free", while cooking a limited firmware for these guys.
They bought Mellanox, the sole infiniband supplier to vertically integrate. Wonder how they will cripple the IB stack with licenses and such now.
They're the Microsoft of hardware world. They're greedy, and don't hesitate to make dirty moves to dominate the market. Because of what they did, I neither respect nor like them.
The linux kernel team should offer a fixed compatibility layer for drivers. And for user applications too, while we are at it.
> You are free to implement it.
But would it be accepted?
From what I see with both NVidia's and OpenZFS's compat layer, it seems to indicate that the Linux kernel folks are actively hostile against any such thing.
(Contrast this with, say, the FreeBSD folks where both the kernel- and user-land API/ABI stays frozen over the life of a major version release.)
I think this is more related to GPL licensing than them not wanting to assist. If it's completely generic then maybe, but how do you argue that the closed source Nvidia license or the dubious license for zfs can be linked to the GPL licensed kernel without being invitation of one of those licenses. Specially concidering how vague the GPL is regarding what it even means to be using GPL licensed code.
If I present an API anyone can use and Nvidia happens to target it it's a different ballgame than if I implemented and shim specifically targeted at Nvidia's binary blob. To my knowledge the latter is a violation of GPL should it be the inverse and therefore an explicit exemption would need to be put in place for the shim in the GPL and that is the showstopper.
Remember when they broke ZFS by marking the "save FPU state" function as GPL-only? Telling the kernel to save registers so they can be used for scratch space is one of the most implementation-independent things you can do.
It's having a stable foundation of the kernel's API that others can code against. As it stands, the (compat) shim layer(s) have to constantly be tweaked for new kernels:
> Upcoming Linux 6.7 release will change a couple of interfaces. Adapt or die!
* https://github.com/openzfs/zfs/pull/15681
And "dubious license"? Really? Given the incorporation of CDDL code of DTrace into macOS and FreeBSD, and of OpenZFS into FreeBSD (and almost into macOS), it seems that license is quite flexible and usable, and that any limitations exist on the GPL side of the equation.
> To my knowledge the latter is a violation of GPL should it be the inverse and therefore an explicit exemption would need to be put in place for the shim in the GPL and that is the showstopper.
How is coding against an API a violation of the GPL? Neither Nvidia's, nor OpenZFS's, code is a derivation of any GPL: (Open)ZFS was created on a completely different operating system, and was incorporated into others (e.g., FreeBSD, macOS), so I'm not sure how anyone can argue with a straight face that OpenZFS is derived from GPL.
Similarly for Nvidia: how can it be derived from GPL Linux when it the same driver is available for other operating systems (and has been for decades: I was playing RtCW on FreeBSD in 2002):
* https://www.nvidia.com/en-us/drivers/unix/
It's one of the reasons the whole DKMS infrastructure had to be created: since API stability does not exist you have to rebuild kernel modules for every kernel—even open source ones like OpenZFS, Lustre, BeeGFS, etc.
* https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support
GPL requires any code linked against it which fundamentally requires it to be useful (Nvidia/zfs linked into the linux kernel to be used in linux) to also be licensed as GPL or GPL compatible. To my knowledge that was the major stopper for zfs and a major stopper for me to use any GPL code in software I plan to distribute. IANAL but GPL is vague enough that it can be argued either way. The "dubious license" terminology was incorrect from me, I was referring to it not being GPL compliant or at least there is skeptocism about whether it is. The BSD license does not have these restrictions and is fine.
Regarding the compat shim, if it has to link to any kernel APIs stability isn't guaranteed, if you want a reasonable guarantee of stability then as one of the above comments mentioned and I alluded to. Do the legwork to allow userspace drivers in the linux kernel, nobody said it's easy and it seems like the consensus is to just keep the shim up to date instead of trying to push that but if you want a stable API to code against that's your path. As was mentioned in this comment section Linus has publicly stated where possible userspace APIs are to be treated as sacred.
They do.
> If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs. How hard can this be to understand?
> WE DO NOT BREAK USERSPACE!
— Linus Torvalds, 2012
And you get to use modern mobile hardware like what a pinephone has.. lose, lose. Especially that modems simply can’t be open-source for the most part due to governmental regulations, so this everything open-source fairy tale doesn’t make much sense in mobile hardware.
Phones aren’t built from a small selection of devices, and they often have patented firmware that the phone manufacturer couldn’t even publish even if they want to. As I shown, look at the best attempt at building an open-source phone. It sucks majorly.
And again, firmware is a separate matter; there's plenty of cases of linux shipping blobs for the device to run, so long as the driver to talk to that device is FOSS.
Because I don't remember seeing any in the source code... But ist be looking at the wrong place.
you're correct, only firmware tree have binary blobs.
You are right, in the firmware tree, not in the pure kernel itself.
you have to not understand the first thing about kernel drivers to even consider binary drivers upstream. for starters, who provides a new binary when the api change every every new kernel version?
I think phone SoCs are the odd ones out, which sadly doesn't mean they'll improve any time soon. Supporting an ABI for binary drivers in Linux might help phones, but it would give everyone else a chance to regress in their support, so I understand Linux kernel developers' position.
Books Browsers Cameras Document readers File management Journals Mail Photos Presentations Spreadsheets Whiteboards Word processors
One hour 39 + 39 seconds in the demo
As others have already mentioned, just stating the facts about long-term support: chromebooks have much longer support than Android devices. Both looking at the 99-percentile, the median, and the 1-percentile.
Chromebooks don't get stupid bugs that require workarounds in userspace like: - BPF maps being broken because someone at Mediatek ran some proprietary static analyser and blindly pushed some fix - Camera only works properly in the OEM app - GL drivers are upgraded once every blood moon and very OEM has its custom GL version - Treble doesn't break because Samsung decided that mount loops were dangerously insecure at a time it wasn't required - You don't need to keep workarounds for mainline kernels that you can't upgrade, because Google/Android forbids you to upgrade your kernel [1]
Android deprecates driver after 3 years [2], so vendor need to do a lot of work on a very frequent basis. As an OEM, I just want to do my (painful) contributions to mainline, and have them maintain it. Android actively hinders me from doing that.
As an Android OS developer, I could go on and on and on about the stupid issues that Android kernels get that Chromebooks don't. All of those issues would happen just exactly the same on Fuchsia.
I'm not saying ChromeOS' development method works for smartphones, it doesn't. I'm not saying it is desirable, I think it isn't (because it completely kills most innovation). But ChromeOS handles fragmentation better than Android on every single criteria you could imagine.
[1] Google/Android added a bunch a new stupid policies that actually prevent me from upgrading kernels on deployed devices
[2] Yes there is actual planned obsolescence nowadays in Android. It wasn't the case few years ago where obsolescence was accidental
Anecdotal counter-point I have a colleague with a Samsung Galaxy Tab A 8" 2019 (SM-T290), and after just 3 years it became absolutely unusable, even after a factory reset. And it's "by design": it shipped with 2GB RAM, which was usable in Google/Android 9 (shipped OS), but just completely dead on Google/Android 11 (updated OS). Obviously I saved that device from oblivion with a Google-less Android that takes half as much RAM.
[1] This is improving greatly in the last year or two, but that probably wouldn't have made it to your chromebook.
The bus on these older model chromebook devices had a choking issue where the kernel would fully saturate the transfer bus and cause a cgroup scheduling strategy to give full priority to the processes using the bus at the expense of the gui. Solutions to this problem include a new NVME or software level cgroup reconfiguration of the kernel to revert scheduling priority to equal across all cgroups.
Or it could be something else entirely, but last time i had this issue and bug hunted it the finding was as stated above.
I also have a Lenovo Ideapad Chromebook running on an Intel 4020 with only 4GB. Despite being slow hardware, it runs circles around the Duet. The 4020 can be sluggish at times, but it never had the big slowdowns of the Duet. It could even run Visual Studio Code at acceptable speeds. Something was very wrong with the Duet. Usually Chrome OS is good on lower end hardware.
- some phones can read from the screen framebuffer, some are write only - a variety of actual chips used for modem, storage, etc.
Technically this one would possibly not be in Fuchsia, though Google let OEMs put so many hooks everywhere in the system that tbh it would still be possible to do this kind of fuckups
> - Camera only works properly in the OEM app
Fuchsia or not, if Google allows OEMs to add custom vendor calls from OEM app to camera driver, then OEM will still be allowed to do that. They could already forbid it in Android and choses not to.
> - GL drivers are upgraded once every blood moon and very OEM has its custom GL version
GL has nothing to do with the OS, GL vendors pretty much ship the same GL across all OS
> - Treble doesn't break because Samsung decided that mount loops were dangerously insecure at a time it wasn't required
This would definitely still happen (in other ways), by all the hooks that Google leave to OEMs to implement their own security systems (and Samsung is the company who brought SELinux in Android, so even though they do a lot of shit, let's not completely ignore them)
> - You don't need to keep workarounds for mainline kernels that you can't upgrade, because Google/Android forbids you to upgrade your kernel [1]
This one, ironically, would STILL HAPPEN, at least if we extrapolate how Android team work. When building Android from main, you get 10000 as SDK version number to explicitly mention that this is a development tree not to be used.
Fuchsia theoretical advantage should be that one will be able to upgrade the kernel without upgrading the drivers. But again let's extrapolate what Android team does: They create new API versions every year or more, and PLAN THE OBSOLESCENCE of those API versions within 3 years. So currently when an OEM write their drivers, they get kernel security patches for 6 years after the release of the "original" kernel of that version. With Fuchsia you get down to 3 years.
I want to re-iterate that even though from that perspective, ChromeOS' approach is ideal, it has issues wrt innovation. I believe that the ideal situation is an open but centralized approach like what we have currently with DKMS on GNU/Linux distributions. Except let it focus on LTS Linux kernel versions, and have flags on the DKMS to allow switching to newer LTS. Here "open" doesn't necessarily mean community-led. It can be very well just be that each vendor is responsible for its own product. So like Mali is responsible for their mali kernel driver, BOE is responsible for their panel driver, etc...
> Availability of software and firmware updates
> (a)
> The latest available version of the firmware shall be made available for a minimum period of eight years after the placing on the market of the last unit of a certain product model, free of charge or at a fair, transparent and non-discriminatory cost. The latest available security update to the firmware shall be made available until at least eight years after the placing on the market of the last product of a certain product model, free of charge.
(b)
> Information on the minimum guaranteed availability of software and firmware updates, availability of spare parts and product support shall be indicated in the product information sheet as from Annex V of Regulation (EU) 2019/2013.
https://eur-lex.europa.eu/eli/reg/2019/2021/oj
I can't find all of it, but part of it is triggered by EU environment protection directives.
Didn't Google push for mainline integration at some point to completely avoid the need for manufacturer specific BSPs?
Is this supposed to be impressive? My current PC is over four years old and I'm in no rush to replace it. The same Linux distribution runs of decades old HW.
As in all things relating to anything stated by Google with respect to the privacy, availability or expected lifetime of a consumer product, the maxim is not even "trust but verify", it should be "distrust, watch carefully, and assume the worst".
Seems like they a) delivered more than initially promised, b) did not drop it just a year after release. How long a support period do you think they actually promised, and where did they promise it?
[0] https://www.androidpolice.com/2016/10/19/pixel-pixel-xl-guar...
[1] https://9to5google.com/2019/12/02/google-pixel-no-updates/
Crouton / Chrostini seem to have a lot of dependencies on the current ChromeOS platform that would be costly to migrate.
Being careful not to make any pronouncements here since I do work in the group, but no, not really.
Crostini is just a fairly standard VM manager with a handful of custom virtio and IPC mechanisms (some of which are really clever, to be fair). It doesn't require much of anything that hasn't been in the upstream kernel for years. And Crouton is just a community-maintained Linux chroot. People (including me) were doing exactly that kind of hack on rooted android devices more than a decade ago.
Of course, running a custom VM image like crostini would require system level support but that doesn't seem like it would be a problem or outside the scope of the avf architecture.
ChromeOS is quite different that other Linux based OSs in that it's supposed to "just work".
https://www.gfxstrand.net/faith/projects/wayland/wayland-and...
And this isn't my area, and I have no expertise to offer except to say that I too am hopeful folks work this out in both a HAL- and open-source friendly way.
And also to say that I'm running routine wayland apps on a chromebook every day and they render and composite just great with Mesa/LLVMPipe contexts, even things like e.g. STL slicers you'd expect to want the GPU. The need for acceleration is real, but limited to some special use cases.
I'm aware of android terminal apps, but they typically connect to a remote terminal via SSH.
Does android boot into a terminal like a typical linux device? I thought it booted into fastboot
> I'm aware of android terminal apps, but they typically connect to a remote terminal via SSH.
You certainly can run a local terminal (I think I've seen it baked in as part of developer options, but also as an extra app), though if you don't have root it is somewhat restricted in what you can actually do.
> Does android boot into a terminal like a typical linux device? I thought it booted into fastboot
I think you're slightly misunderstanding how boot works on both Android and Desktop Linux. The kernel is perfectly happy to run whatever you want on such displays as are available. Android tends to boot from firmware (which also implements fastboot) to a bootloader to the kernel and the kernel brings up the system with SurfaceFlinger (the Android display manager) owning the screen. On desktop linux there's more diversity; you can have the kernel initially hand your screen to the old in-kernel virtual terminal, the newer KMS implementation of a terminal ( https://wiki.archlinux.org/title/KMSCON ), or to Xorg or a Wayland compositor (in that case, optionally using plymouth or the like to replace even the earliest text messages). (Actually, full disclosure: I'm only about 70% sure I've got that sequence right. The point is that even desktop linux is perfectly capable of booting only in graphical mode; booting to a text terminal is available but optional.)
It's possible you are a wizard and I'm a novice so I can't wait to see your demo soon.
All of the concepts as you've described will take some dev time to actually turn into a product.
It took Google years to make Linux VMs part of the ChromeOS product and that was with a working hack solution already available for them.
My point is that your theory will not be shippable on day one.
If the future ChromeOS-Android hybrid (ChAnroid?) loses Crostini Linux, but is able to run Android applications then Termux might be a good option depending on the task.
Aside: this ChromeOS-Android merge brings to mind the Chenjesu-Mmrnmhrm merge to create the Chmmr in SC2. Maybe the ChromeOS-Android merge will similarly yield a wonderful hybrid result?
I'm having a Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch moment here
It does seem that new Android lets you turn off the phantom process killer, so maybe there's hope, but still Termux is forced to target an old API version and can't be published on Google Play.
settings put global settings_enable_monitor_phantom_procs false
The more pressing issue at this time is: https://github.com/termux/termux-app/issues/2155
High fives!
My main Linux computer died a year ago and I needed something to write emails and browse on, so I ran out to Costco and got a Chromebook, expecting it'd tide me over until I could figure out a replacement computer.
I'm still on the $250 Chromebook machine. It does everything I need and I'm pretty amazed at that. I've been doing some side projects with Elixir/Phoenix and it's not the speediest machine for sure, but it's quite serviceable. And for that price... that's amazing.
I went full Linux on it using MrChromebox[0] a few years back with zero complaints.
I've ended up gifting the 4 or 5 budget chromebooks to nephews , pre-installed with Crouton / Crostini set up and accounts on leetcode / hackthebox to train on.
It's remarkable how capable Chromebooks are. I tried using my $600 iPad Pro to code on and I never found it to be as capable as my $200 chromebook
Once I get my office situation set, I want to start doing everything on an RPi.
TL;DR: Google is consolidating behind the whims of the hardware org, which are orthogonal to OS' that can't ship (what ppl outside Google call Fuschsia), and here, OS' that can't sell premium 1st party hardware. The old platform org head left recently, combine that with the CEO's eagerness to display Efficiency™ and the lack of interest the CEO has in practical work, that means VP shuffle people around to keep constant/shrinking headcount and the CEO loves it.
I hope your day gets better! However you're feeling, it's temporary, it's not worth trolling and doing a know-nothing thing in public, it's too demeaning to yourself.
People can see my comment, profile, and site, and then see you're completely anonymous.
Then they're left with either: A) you're so hung up on an extra S you're lying on purpose B) you're a vindictive liar: you don't care enough to find out who I am, even though it's right in my profile, but you do care enough to pretend it's unknowable or C) youre having some sort of psychotic break from reality
I don't know anyone outside the Fuchsia team that takes it seriously.
Because they are panicking and need to add AI faster than Apple and Microsoft across their whole portfolio.
A big advantage of Android is the implementation of intents (also compared to Apples new crippled intents API), which may turn out to become the deciding factor in the race towards the winning AI Agent OS, as it may enable AI to use programs programmatically
As building an OS is no simple task, this all could mean nothing and the project might be heading to the graveyard slowly.
I noticed the same, too, it was hyped as the next OS now about a decade ago, and it doesn't look like it will be a significant player any time soon. I assume it's still in the evaluation, prototype phase, probably tons of issues.
I heard here and there that some exotic glorified home tablet thingy is running it, but I don't think you can really go to a local consumer electronics store and find something with Fuchsia running on it.
I don't necessarily think it's going to be a major success, but it's already been more successful than this implies.
(Bias, was on the Fuchsia team many moons ago)
There is not much actual difference between "I heard here and there that some exotic glorified home tablet thingy is running it" and "There are multiple devices that have shipped with Fuchsia on it in the home ecosystem over the last 5 years".
Would love to hear where it was actually used, searching for it, I really only found a handful of examples.
I was an active Flutter community member and it was driving me crazy how people would say "Flutter is great because Fuchsia also uses Flutter", and all I thought "show me one person who is using Fuchsia at this whole conference / meetup".
So it would be Android, Chrome-on-ChromeOS in an AVF VM, Linux-on-ChromeOS in another AVF VM, Windows in a third AVF VM, etc.
The question is will they also throw out the ChromeOS userspace components and replace them with the android userspace?
If so, this is effectively an announcement that ChromeOS is discontinued but those devices will now be migrated to run android.
[0]https://source.android.com/docs/core/virtualization/architec...
[1]https://www.androidauthority.com/chrome-os-on-android-hands-...
https://android.googlesource.com/platform/system/update_engi...
Many Android specific changes though.
There are also tools available like Andronix.
I personally haven't tried them, just figured I'd leave the information here for people interested in it who want to explore the options.
I know it isn't very secure. But certainly better than having a seed locally stored.
Battery life not so much.
The ux is kind of junky, but if you're mostly using the browser or some remote desktop / ssh it's feasible at least.
[1] https://chromium-review.googlesource.com/q/status:open+-is:w...
Looks like we can try to infer the real intention of the convergence from this project. It might make business sense to maintain 3~4 different OS, each targeting different user segments. But there is no reason to have one more different tech stack per each OS across everything.
My memory was maintainers on the linux side had an issue with wakelocks maybe? At one point google going to some pretty serious lengths to try to integrate / upstream some stuff and it getting totally shot down.
My own view was there was a bit of a missed opportunity there
At this point, Androids kernel is only a fork of upstream Linux kernel because Google employs so many kernel devs that some features are developed downstream first, then upstreamed once kinks are worked out after shipping in devices on tighter deadlines than upstream.
ashmem is user space shared memory with permission controls. It was replaced(ish) with memfd with the addition of F_SEAL_FUTURE_WRITE in 5.1 (it took a shockingly long time for that to finally have feature parity but hey better late than never)
ION is the special allocator that was replaced with dmabuf.
Also ARM, qcom, etc... all love playing with the scheduler or making other changes which typically happens downstream first for time-to-market reasons before being upstreamed. eg, ARM's EAS / energy aware scheduling I think actually shipped to users prior to upstream accepting it.
Linux at that time was very much unequipped at handling low power devices well (e.g. Wakelocks have already been mentioned).
Simplifying engineering effort and merging the stacks, that I can understand.
Thousands of distros and not the one that would take off. Sad!
And now, with this announcement, the moment has passed.
... that would just be Linux then? GalliumOS was Ubuntu for Chromebooks (with ChromeOS patches for touchpads etc). Mainline Linux is good enough nowadays for most things.
Several companies offer custom ChromeOS images with their own tools and one was even purchased by Google, but they focused on centralised management for classrooms etc.
Maybe it is more about the business model. ChromeOS runs efficiently on low-cost hardware for a small license fee (?), and get almost guaranteed updates. In exchange, customers sell their souls (actually, data) to Google. Won't happrn with Linux. But undeniably it sells and works well enough for ChromeOS.
You mean "ChromeOS community", right?
I tried to make a custom container that would run under the regular ChromeOS crosvm, all the "agent" stuff for e.g. transporting wayland over virtio is brittle crap that crashes with no useful error if you don't invoke it perfectly correctly.
What I want is the idea of wayland-over-virtio to be reimplemented by others.
They had to get ahead of rampant internal rumors that were leaking externally (c.f. comment of mine a couple weeks back https://news.ycombinator.com/item?id=40580163)
Let's stop begging at the table of big-tech for software scraps.
There's been plenty of HN readers on here over the years touting Fuschia as the next big thing to displace Linux/MacOS/Windows due to the Pure Microkernel Design(TM), mish-mash of C++/Golang/Rust in said microkernel, and the fact that it's a Google Product. All the things HN loves.
Google's operating system is android. it has won. extend that architecture to the chromeos.
There was a time when the chrome team were walking around telling everyone native android development was a dead end and chrome would take over everything. Then Google had some reorgs, certain people ascended to control both android and chrome, and suddenly android was a good thing.
There's technical merits to both platforms. The fact that Google had/has multiple Linux distributions all competing is ridiculous. I personally worked on HW products that used... (counts fingers) 4 of them? And then toss Fuchsia in there, too...
Android has its place on mobile, but we see how well it has gone for Microsoft trying to take a single OS and make it work across mobile/tablet/laptop.
Also WRT your problems: In case you did not yet, switch to Pipewire. When I did that a couple of years ago, my BT Audio experience went from bad to really good.
For example, I have JBL headphones, that work perfectly in the A2DP mode; but switch to HFC for the mic, they will work for a few minutes, then drop off and stay that way until reboot.
That's with Ubuntu. With Android, no such problem.
https://chromeos.dev/en/posts/androids-bluetooth-stack-fluor...
Catastrophizing maybe a little bit, but this sounds like turning their back on the broader ecosystem to go wander off for good in the 3rd rate sandbox they built themselves. Android has spent years trying to figure out our to have a secondary display, and the only thing they could manage was to mirror the display, almost certainly in sizable part because Android's boutique homebrew display services are so absurdly constrained. Marrying yourself to this boat anchor of a tech stack is the worst possible move ChromeOS could be doing.
Google's Not Invented Here has always been exceedingly high. ChromeOS has been one of the only attempts Google has made to play well with others, to carve some kind of middle path. It's hard to read this as anything but Google giving up & deciding to go it alone.
They should have done the exact opposite. They should have made Android start using ChromeOS. Or just stay the course. Yeah it's costly having parallel efforts, yeah, but holy heck these feel like existential stakes if you get it wrong, and no longer having anything that interoperates with the rest of technology seems like an obviously hideously bad idea, trusting everyone will adopt your stuff seems bad; Microsoft for example has finally dug themselves out of this hole with WSL, but Google already has a very respectable sensible option they seem like they are about to kill.
Also, seems likely Google was lying a month ago when they said ChromeOS on Android was just a demo. This announcement shows it was their battle plan. Just, not to users benefit, not as a "your phone can also...". https://news.ycombinator.com/item?id=40380022 https://www.androidauthority.com/chrome-os-on-android-proof-...
It only took two months since teams were merged for this awful no good way to throw away so much greatness to go public. https://www.tomsguide.com/ai/android-and-pixel-teams-merge-i...
They created something, only to never ever use it in public eye. To go keep reinventing and keep NIH'ing. The android virtualization stack is fucking wild, and hardly used, offers such a meager fraction of what ChromeOS was doing.
Not a bad callout, but this seems like a particularly glorious & vicious slam... that doesn't change the big picture on iota.
Containers on UNIX and mainframes predate Google's existence.
It probably would work out better in the long run considering I keep on seeing more pushes to have Android be usable on "desktop sizes", which with their mostly Wayland stack on ChromeOS would allow a lot of desktop native apps to mostly work.
The other problem is that other vendors do not provide chromeos versions of their tools. Looking at you Fortinet and your vpn.
Now, a ChromeOS Notebook or even better an Android Tablet with a ChromeOS style Desktop mode getting the GrapheneOS Treatment would be an instant buy for me.
I don't quite understand why it couldn't accept a larger internal hard drive, but if it could I don't know why "up to 1 TB of NVME storage" would be their marketing copy.
[0]https://frame.work/blog/introducing-the-framework-laptop-chr...
>Memory and storage are socketed, enabling you to load up whenever you’d like. The pre-built configuration comes with 8GB of DDR4 and 256GB NVMe storage and can be upgraded to up to 64GB of DDR4 and 1TB of NVMe storage.
With regards to the memory I went looking and the framework has 2 ddr5 laptop dimm slots. The largest I was able to find were 48 gb modules so the physical limit may be 96gb.
And as a closing note, this was the first time I really looked at the framework laptop page. And while I am still not sure about the build quality or the usefulness of the "ports". the number of guides and photos of laptops under surgery sold me, I think I found my next machine.
It has to be something like that. That's a standard length M.2 slot...
> https://community.frame.work/t/will-framework-chromebook-wor... Installed WD Black SN850X 4 TB (WDS400T2X0E) on my Framework Chromebook. I’ve been using it for a month and a half now. Everything is fine. The only point, probably due to which the use of such disks is not officially recommended, is the excessive reserved space for the OS. Apparently this is a legacy of the times when disks in Chromebooks were of small sizes. If you are happy with the situation where a quarter of the disk will be idle for technical reasons, then you can take it.
But I'm struggling to think what a 64gb of RAM with a GPU Chromebook could do that the current ones can't do? If it's run Linux, why not just get a Linux laptop?
You can maybe get this with some Linux laptops, idk. The Thinkpads we have at work that "support" Linux have known Bluetooth issues; if I ever have trouble hearing someone in a remote meeting, it's someone with a Thinkpad.
If you buy something like a Dell, you might encounter more rough edges, although it's generally not as bad as it used to be 1-2 decades ago.
And Surface runs Windows. Gonna plead the fifth on that.
(Qubes is close, but does not verify the whole stack against hashes stored in a secure enclave on every boot. Also, Qubes has a much lower bus factor.)
Maybe Vulkan support through Linux (only HW accelerated OpenGL GLES works right now for me)
Screen was super nice though. It was never worth $1000
Mine in particular died a slow and painful death. The thermal paste had aged out, and the fan died, though was cheap and easy to replace, but even after, it still was nonfunctional, as it would die after being on for just a few minutes. Because it was running Linux with weird userland stuff like Crouton, it was devilishly hard to debug. I also just do not know how to debug Linux nearly as well as I understand Windows "internals".
It's too bad because it was a pretty laptop with a very nice screen.
We have a few in the office and they are surprisingly OK. Let down more by the weaker processor (i3 instead of i5) but workable for a lot of things.
(because even back in the day, if the phone was powerful enough to run java, it was powerful enough to compile java)
"Industry forms consortium to drive adoption of Rust in safety-critical systems" (2024) https://news.ycombinator.com/item?id=40680722
That’s true today but what about in the future
---
Hm. So I can tell you in practice I've used programs compiled against RHEL 5 on RHEL 7, and programs from Ubuntu 16.04 on 20.04, but that's not a formal commitment. It may be a limitation of my search skills, but I can't immediately find a formal policy/commitment. There's this:
> One of the GNU C Library's (glibc's) unwritten rules is that a program built against an old version of glibc will continue to work against newer versions of glibc.
- https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-...
...but that literally calls it an unwritten rule:)
There's this:
> The current GNU C library provides the run-time backward compatibility. That means executables and shared libraries built against the previous versions of glibc will continue to work with the current shared glibc, libc.so. This functionality is implemented with the symbol versioning in libc.so. This work is based on the effort from Eric Youngdale.
- https://mirrors.edge.kernel.org/pub/software/libs/glibc/hjl/...
...but that page talks about RedHat 6.2 in an active sense. Not RHEL 6.2, RedHat 6.2.
The final place I thought to look was to search through https://sourceware.org/glibc/manual/latest/html_mono/libc.ht... for "backward", but that seems to only talk about compatibility with BSDs and the like, not this.
So I got nothing.
I usually am able to get binaries running across distros myself but at times it involves messing with linker paths and setting up hacks symlinks. I don’t know what’s up with that or how it can be improved to “Just Work TM”
It is also going to be a bitter pill for many Chrome OS people, who were often defined by a distaste for Android that verged on the absurd, and caused an awful lot of political nonsense. Android is far from ideal, but Chrome OS was better in one sense only: security.
Controversially I believe the most viable future Linux desktop is likely to be based on the Android stack, especially the app packaging, but with the entire “java” layer removed.
Don't you think this is a pretty major feature?
Android does a huge amount more, especially around media and general hardware support (such as nn accelerators) which make security much harder but are also necessary for deploying modern applications.
The low level pieces of Android have dramatically improved over the years though, and are clearly battle tested at enormous scale. Binder, of recent security problems, is functionally very useful. The graphics system handles DRM and HDR on different hardware surprisingly well these days, and even the audio stack is far less annoying than it used to be. Considering that Android devices are expected to run continuously this is no small achievement. Some years ago I wrote and deployed Android code that decodes and plays video, with audio, constantly, for months on end, synchronized to an external clock, on a random cheap OEM board, while downloading the next one over a flaky network, with relatively minor alterations to the OS being necessary. It may be possible on other things but I would probably still be debugging it.
https://www.chromium.org/chromium-os/chromiumos-design-docs/...
What would replace all the APIs provided by the Java layer? Compared to what you find in traditional Linux desktops, the Java APIs are
1) comprehensive, providing a one-stop shop for basically all core app functionality; desktop Linux has no equivalent of the Android SDK or the Windows API.
2) versioned, with strong backward compatibility.
Linux desktops have no well-defined "minimum API version" that developers can target like they can on Android.
Of course they do: "Ubuntu 16.04+", " Debian 11+", "RHEL-like 8+". If you can use a single distro (which you're proposing anyways with Android), it's not hard. Sadly LSB didn't really work out so you don't have a more portable solution, but that just means that we're stuck with the status quo and not better.
The key problem with desktop Linux is the entire distro concept. Just have the kernel, some services (the android ones like binder, surfaceflinger etc) and go from there. Iirc that isn’t far from what firefox os was, only they insisted on everything being browser based.
The Java API on android is thinner than it looks, and contains most of the serious problems, such as the entire UI stack. Now that Swift has grown static Linux support that would probably make most sense as the first class target for API consumption.
https://news.ycombinator.com/item?id=36998964 :
> Students can't run `git --help`, `python`, or even `adb` on Chromebooks.
> (Students can't run `git` on a Chromebook without transpiling to WASM (on a different machine) and running all apps as the same user account without SELinux or `ls -Z` on the host).
> Students can run `bash`, `git`, and `python` on Linux / Mac / or Windows computers.
> There should be a "Computers for STEM" spec.
Docker containers can be run on Android with root with termux:
- https://gist.github.com/FreddieOliveira/efe850df7ff3951cb62d...
Podman and podman-desktop run rootless containers (without having root).
containers/container-selinux: https://github.com/containers/container-selinux/tree/main .spec: https://src.fedoraproject.org/rpms/container-selinux/blob/ra...
"The best WebAssembly runtime may be no runtime" https://news.ycombinator.com/item?id=38609105 : google/minijail, SyscallFilter=,
E.g. https://vscode.dev/ runs in a browser tab on a Chromebook and supports Pyodide and IIUC hopefully more native Python in WASM support soon?
Hopefully Bash, Git, and e.g. Python will work offline on the kids' Chromebooks someday.
Its neat to be able to just carry around a mini desktop computer
Uhm, is there any plan to bring some openess to it so one can actually run python and do ML without using some alternative hack? How is the state of these things nowadays for chrome os? Haven't played with it in ages.
Is it just because it's easy, somebody picked it a while ago, made something influential, and now everybody uses it because everybody uses it?
Also, python is just the glue, the work happens in libraries.
Likewise I wouldn't use Python for anything besides teaching programming, or scripting OS tasks and native libraries.
And I think Python's package management and parallelism are both awful in ways that could've been avoided, or fixed during that huge breaking Py2->3 change. And I prefer JS syntax. But it still works.
- python integrated well with lesson plans instructors had
- python integrated well with the software math departments were using (like MATLAB)
- python had a very easy to use interpreter environment that worked well on linux, mac, and windows
- python had (for the era) a massive standard library, making it way easier to consume and process
common data file formats like XML or CSV without having to install any extensions
(installing extensions usually required admin permissions and... very few at school had those for very good reasons)
- exposing c/fortran libraries into python was pretty straightforward to do and was relatively stable compared to alternatives.
- tcl - somewhat popular for embedding but didn't really have a standalone interpreter that made it easy to interact
with and the syntax didn't really look like C, and really not much of a library to work with
- lua - similar to tcl, popular for embedding but didn't have a popular standalone runtime and interpreter.
syntax was closer to C though. didn't have much of a library to work with
- ruby - had a runtime for experimenting but a less stable API for integrating, plus the language was pretty
different from C. the library was large but had a larger reliance on installing extensions than python at the time.
- perl - both unstable and had a horrible reputation by this point as a standalone language that outside of some obtuse
systems scripting, most people didn't want to touch this with a 12-foot pole. standard library was small and relied a lot on extensions.
- php - similarly unstable (at the time... i think 5.3 had just come out) and had a horrible reputation... also not even
sure it had a runtime that worked outside of an apache/nginx context... exposing a c library to PHP at this time was pretty
straightforward though. relied very heavily on extensions at this point.
- javascript - node.js hadn't come out at this point... so the idea of running javascript outside of a browser window wasn't really a thing yet.
I believe that led to a first-mover advantage that has held over time.
And the little scripts I write at work tend to grow and then turn into full-fledged services in a shorter period of time than it would've taken to set up the C++ or whatever boilerplate.
Huh? Please elaborate. The backwards compatibility is excellent. The core has been rock solid since the 90s. Especially compared to Py -2-to-3- thon.
You look like never touched Perl seriously, Raku it's still a hard deviation.
No one used Perl6 on real life environments. It's the Duke Nukem Forever of the programming languages.
Using Perl6 as an argument on Perl5 it's like bashing the simple and clean ANSI C giving C++ as the example and its the crazy redundant features as a rant.
We're talking about the choice of Python for ML when CUDA came along, nearly 20 years ago. Upthread, alaties said:
> Around 2007, the main competitors in the scripting space had a lot of issues: [...]
> Perl [...] unstable
RadiozRadios replied:
> Huh? Please elaborate.
I did.
In 2007, Perl 6 was not Raku, it was intended to be the next major version of Perl. But it had been in development for ~7 years already, couldn't be relied on or predicted, and had become a bit of a joke. Since Perl 6 was still supposed to be the future of Perl, in 2007 Perl very much seemed unstable and unsuitable as a foundation for ML research.
Well, it's as true of Guile as it is of Tcl and Perl...
Ew. ChromeOS was always a beautiful contrast to Android, running mainline kernels instead of Android's hacked up mess.
Actually that was pretty much true of the rest of the stack as well - ChromeOS was almost a normal(ish) GNU/Linux, running Chrome on Wayland on ~Gentoo. Android, in the meantime, NIHed the whole stack. I had always dreamed that one day Google would rebase Android to use a ChromeOS base running apps through a compatibility layer. This... feels like the Bad outcome.
This is at least partly because the two are distributed very differently, with Chrome OS on a much shorter leash than Android, even with Play services.
With Chrome OS devices Google can push updates to any device whenever they want, whereas with Android it was often up to the manufacturer, or even carrier, which many Googlers (not all) considered to be a mistake.
But this is also the Chrome OS achilles heel because support for esoteric third party hardware blocks is the Android killer feature and now more important than ever.
You could beat all of this into submission but you'd end up rewriting a lot of stuff anyway, because those things need to be designed with it in mind (PulseAudio never had a concept of permissions and in practice you had to live with that until PipeWire was written from scratch.) The Linux desktop is a big project with a lot of stakeholders in various projects and many of these ideas only really came into the desktop realm in the past 15 years or so. This means progress is relatively slow all things considered, compared to something like Android or ChromeOS, with unified teams and top-down vision, which is why they have more or less completely replaced the entire Linux desktop in that same timeframe and even delivered on things it still doesn't have like HDR, per-application sandbox and permission models, etc.
I do think that in the server space, you can produce reasonably secure and trustable Linux systems based on available distros. But on the desktop, well, it's not so hot.
Wait until you discover exploits for the rust Runtime
>no accessibility
AtSPI, speech-distpacher.
>no fine-grained permissions system,
ACLs.
>no normal cross-application communication
DBUS did that.
>No userspace resource control (cgroups are cool, but they are not exposed)
Unless you use Plan9/9front, every Unix and even NT it's like that.
Inb4 sandboxing and X.org easy eavesdropping, upon running any unsupervised malware as your user account, you are powned under every OS (by default) as you can just tgz the Chromium/Firefox/SSH profile from $HOME and rsync+netcat/NNCP the whole pack over the net. Everything else it's snake oil.
That literally wouldn’t work on Android, or ios. And android’s solution is very elegant, and only relies on standard linux interfaces, so there is zero reason why running every process under a new, dynamic user is not the default way of interaction.
I wished and hoped for the same (or at least, for ChromeOS to not get cannibal'd by Android). But...
> This... feels like the Bad outcome.
Realistically, running apps inside of a language runtime (VM) is bad enough for an embedded device (the HP Dynamo-like gymnastics to speed up ART, notwithstanding)... and here we were wishing each app ran in its own guest OS?
And: The strange case of VMs on telephones, https://apenwarr.ca/log/20100826
It's hard to not cynically read this as "we're making it easier for our partners to ship devices with vendor kernels".
I'm pretty shocked. I would've bet good money at this having gone the opposite direction, with ARC already on ChromeOS, etc.
blinks rapidly
edit: I guess if you squint really hard to read "Windows" as "PC-style operating systems" (or "general purpose computing") it makes sense?
Linux laptops still tend to be special order or niche brands, but there is nice positive traction in that space.
The Google userland programs are removed but the kernel and drivers are retained.
This frees up lots of storage space to be filled with the owner's choice of open source userland programs.^1 Read-only filesystem, "powerwashing" system recovery, open source bootloader. Chromebook without the Chrome.
Not for commercial use but for recreation and experimentation. For commercial/educational use people can use a Chromebook from Google. I have heard that some people own more than one computer.
What some (not all) computer users want is an inexpensive portable computer that has excellent hardware support in the Linux kernel. These users users are capable of administering their own computer and have no inclination to let a so-called "tech" company remotely install software on their computer at any time ("updates"), use a web browser distributed a so-called "tech" company, store their personal files in "the cloud", i.e., data centers belonging to so-called "tech" companies, remain "logged in" to servers operated by so-called "tech" companies 24/7, and so on.
These users want a "Chromebook from scratch".
Source-based, but Google does not control the source.
1. If an owner wanted to retain some of those Google-authored userland programs, it may be possible for the owner to compile them herself, e.g.,
Google has obviously been working on AI stuff for quite a while. I mean Gemini exists, to pick the most obvious example. And since the industry is so gung ho on AI you know they were going to be pushed on device/OS integration pretty soon no matter what.
Microsoft recently announced their new Copilot PCs. In some ways that was a hardware announcement but they also got something of a blackeye for the recall feature.
Two days after Apple announces all sorts of AI features on all their OSes (except vision) coming to many of their devices soon this announcement suddenly shows up?
They’re the only big company with a consumer OS who hasn’t announced their plan yet. This feels a little bit like a “don’t forget about us“.
I will be very curious to see what they do when they put out more concrete information.
Next 5 years will be much more interesting than the 2 years before.
It will likely be at least a year before Google manages to get a good version out the door. You can preview the desktop mode with floating windows on beta, but it's very buggy. May not even come to Pixel 8 officially, only for Pixel 9.
https://android.googlesource.com/platform/packages/modules/V...
What's special in Android is multi-process. All (Kotlin/Java) apps fork from the same base runtime image, regions of which are CoW'd when mutated.
After a bit of reflection, here are a few of the things I recall hating:
* Really difficult to intercept HTTP requests, especially when testing. JS makes this easier, and obviously much more insecure, but getting things done...
* The permissions landscape always felt like it was shifting. Chrome apps have their own issues, but I still get confused when I see a permissions dialog on Android. I am sure there are good privacy reasons for all of the permutations, but I bet the permissions were not created by the same PM at Google each time.
* When I last did Android the layout system was converging to constraint layout, and it was an improvement over the prior ones. But, when I compare that to the simplicity of flex or grid layouts in HTML, I prefer those.
* All the damn targets for compilation. It is so much easier to just have to build to a webview that runs on whatever architecture you need than to figure out arm or x64.And the latest APIs are very sexy.
x86 has been pronounced dead many times, yet hasn't yet happened. Maybe this will be the one but against all odds, and reason, x86 has continued to thrive.