HN user

shasheene

1,271 karma
Posts5
Comments163
View on HN

I'm still sad that Linux dropped support for i486 and early-i586 CPUs.

And more disappointed that distributions especially Debian the "universal operating system" has dropped support for i586 already (and is dropping support for i686)

Open-source doesn't have the same pressures of commercial software from Apple or Microsoft. I really love the idea of obsessive, perfectionism approach of providing indefinite hardware support to obscure old hardware (but especially once-popular old hardware), with adequate automated testing suites to test ancient hardware.

Maybe with agentic AI coding we'll be able to expand support windows, and even bring back hardware support for older hardware.

the project lead, Rudra B. Rudra, has had less time to dedicate to the work recently. As a result, the team could not ship a stable 25.10 release this October.

That may not be the biggest deal, because Ubuntu 25.10 itself is not going to be stable, thanks to switching from GNU coreutils to the uutils Rust rewrite, with Ubuntu 25.10 being a "see what breaks and fix it" canary before the long-term support 26.04 release in 6 months.

I think this is premature and a big mistake for Linux.

The costs of distros and the kernel steadily dropping older x86 support over the last few years never causes an outcry but it's an erosion of what made Linux great. Especially for non-English speaking people in less developed countries.

Open-source maintenance is not a obligation, but it's sad there is not more people pushing to maintain support. Especially for the "universal operating system" Debian which was previously a gold standard in architecture support.

I maintain a relatively popular live Linux distro based on Ubuntu and due to user demand will look into a NetBSD variant to continue support (as suggested in this thread), potentially to support legacy 586 and 686 too.

Though a Debian 13 "Trixie" variant with a custom compiled 686 kernel will be much easier than switching to NetBSD, it appears like NetBSD has more commitment to longer-term arch support.

It would be wonderful to develop systems (eg emulation) to make it practical to support architectures as close to indefinitely as possible.

It does feel like a big end of an era moment for Linux and distros here, with the project following the kind of decision making of big tech companies rather than the ideals of computer enthusiasts.

Right now these deprecation decisions will directly make me spend time working at layers of abstraction I wasn't intending to in order to mitigate the upstream deprecations of the kernels and distros. The reason I have used the kernel and distros like Debian has been to offload that work to the specialist maintainers of the open-source community.

Debian's tagline is the "universal operating system". It's a distribution with active ports on a very large number of architectures [1], even incredibly obscure ones.

The goal of universal compatibility that separates the Debian project from commercial software and even other open-source projects.

The legacy x86 architecture is still far more popular than some that platforms that Debian advertises as having official support for and there has been x86 based processors manufactured for niche applications until recently, eg, AMD Geode and others.

I find it really unfortunate Debian Project is removing official support for new x86 installations. The silver lining is it seems like they'll be an unofficial port and it's likely niche distributions like MX Linux and AntiX will maintain their own builds.

It would be ideal if open-source can develop stronger mechanims to keep support for the large numbers of these relatively niche architectures (eg, through increased usage of emulation over real hardware).

[1] https://wiki.debian.org/SupportedArchitectures

Oh finally! I have a Kindle Scribe, and it's really amazing hardware, but it's unusable for reading websites like Wikipedia and sending links to it using the Amazon bookmarklet is a pretty bad experience.

The biggest issue is the web browser doesn't have pagination, ie a next page button. *It only supports smooth scrolling using the touch screen*. Which on an e-ink display is a completely awful, insanely frustrating experience that I can't believe they ship it (and the Scribe is an 11th generation product).

Using a web browser to read pure text is a blurred mess that's takes several painful seconds to slowly scroll to the next page.

Since I bought the Kindle Scribe (big mistake due to the above issue), I've wanted to jailbreak it to install a non-terrible Wikipedia browser.

Eg the one available in the KOReader project -- the open-source alternative eink-optimized ebook app that is widely-supported across the eink ecosystem (including older Kindles).

Thanks for heads up that a jailbreak is finally available!

SpaceX and T-Mobile are starting a trial in late-2023 to use unmodified handsets for text (and later, voice and data) with the Starlink V2 network to remove cell coverage dead-zones. [1] [2]

It's achieved by "dedicating a slice of T-Mobile's Mid-Band PCS [1.9 GHz] spectrum, to be integrated into Starlink satellites, launched next year", with each Starlink V2 satellite hosting two 5-6 meter long cell-spectrum antennas, in addition to the existing Ka- and Ku-band antennas.

They're aiming for the US with the trial, and growing to global coverage by entering into reciprocal roaming agreements with the international carriers who hold licences to the relevant mid-band spectrum.

Elon Musk says "this won't have the kind of bandwidth that a Starlink terminal would have, but it will enable texting. It will enable images. And if there aren't too many people in the in the cell-zone, you could even potentially have a little bit of video."

Musk claims 2 to 4 megabits per cell-zone, 1000-2000 simultaneous voice calls per cell-zone, with the cell-zone of course being much larger than a terrestrial cell-tower.

[1] https://www.t-mobile.com/news/un-carrier/t-mobile-takes-cove...

[2] https://youtu.be/F8zS2rU-URo?t=325

Yes, Patreon's WYSIWYG editor is incredibly buggy.

But far worse is Patreon's messaging platform. Write a long message, then accidentally have a window resize event occur and lose your entire message.

Patreon's problem with losing text has burned me more times than other products with similar issues (like creating a Jira issue).

Some platforms like Slack do a much better job of saving a draft.

I'd argue Joe Manchin (Democratic Senator of West Virginia) has single-handedly changed an eye-watering $3.5 trillion dollar spending bill into what appears to be a slightly less eye-watering $1.5 trillion package. The lower number (and thus lower taxes) makes it much more acceptable to a broader fraction of US society. Assuming the bill passes, it's an example of compromise working (but within negotiations of a single party).

The key thing is if one party wants to be able to pass the larger number without that pivotal vote, they need to appeal to a greater fraction of society and win more seats so they don't require that particular vote.

Two houses helps prevent tyranny of the majority. Consider the United States. Each state gets 2 senators no matter what, but the proportion of House of Representatives seats each state gets is calculated based on the state's population.

This quirk means that even small states like Wyoming have equal Senate representation as the populous states like California, Texas or New York.

This arguably undemocratic over-representation gives the smaller states much more power in certain areas, but this is by design. It provides incentive to keep large rural states part of a single nation. Compromises like that makes a country as a whole stronger.

Another interesting aspect is US Senate terms are long (6 years), with a third of members up for reelection happening every TWO years. Compared to the House of Representatives which has 4 year terms, and half up for reelection every 2 years. The net effect is it requires several election cycles to have a big impact on the passage of laws. This contributes to stability.

The new Sourceforge team has generally done a great job. Here is a review that might help some people.

Pros:

For general project discussion, Sourceforge's traditional discussion forum is far superior to Github/GitLab issues (though I haven't tried Github Discussions beta yet). The forum can be configured for users to be able to post without creating an account (though only as a specific user named "Anonymous", not arbitrary names) which is as important feature when creating software for users who aren't likely to have Github or Sourceforge accounts.

Sourceforge download statistics tracking of releases (including graphing per country and with arbitrary timestamps) is far superior to Github, which doesn't offer even private tracking of download numbers without directly using their API. This is actually a really ridiculous situation.

Cons:

Sourceforge recently added the ability for the project administrator to mark any review as spam, which automatically hides it. This single change has completely ruined the trustworthiness of Sourceforge's reviews, as unscrupulous application authors are able to mark all poor reviews as spam so users only see good reviews. Because of this, I recommend AlternativeTo (http://alternativeto.net/), as they have better review non-interference policy.

Sourceforge's entire website seems to go into maintenance mode for a few minutes every 24 hours, which is frustrating for those in less favorable timezones.

Even after using it for a long time, Sourceforge user-interface and settings/permissions is overly complex, confusing and non-intuitive. I find Github's well designed settings page much easier. Though admittedly Github has its share of UI quirks. New Github users are understandably initially confused by the concept of Pull Requests (which should have been called Merge Requests) and the fork user-interface. As a developer familiar with both tools (and git, PRs etc) I find Github easier to use than Sourceforge, which is saying something.

Many Sourceforge projects tend to have their source code mirrored on a rarely updated Github project, which then gets forked and developed without changes being upstreamed, which causes fragmentation.

Many third-party tools (like CircleCI) tend to target only Github (and to a lesser degree GitLab/Bitbucket) and ignore Sourceforge entirely.

It's too easy for newbie users to download older releases (Github has the same issue unless you create a Github Pages site to highlight the most recent release).

Conclusion:

Sourceforge is actually a reasonable tool to develop open-source software in 2021.

For new projects I would generally suggest sticking with Github and GitLab, but for existing projects on Sourceforge changing hosting to Github may not be required.

The real killer is lack of integration of third-party tools like CircleCI. That's enough to switch to Github. But you will likely miss the excellent download statistics, anonymous support forum and user review system.

Ubuntu at least does it in alphabetical order of the first letter of the codename. Eg, the release after Ubuntu 20.04 Focal was Ubuntu 20.10 Groovy. This means that hearing the Ubuntu codename "Bionic" provides some information: it was 4 releases before Focal.

But Debian codenames are arbitrarily based on characters from the movie Toy Story, so there's no relation to the Debian release.

To fix this, I propose for future releases the Debian codename naming scheme be replaced with numbers written out in words. Eg.

Debian 14 (fourteen)

Debian 13 (thirteen)

Debian 12 (twelve)

Debian 11 (bullseye)

Debian 10 (buster)

Debian 9 (stretch)

Debian 8 (jessie)

This retains the ability to easily search for eg, "Debian Thirteen", while making it much easier to remember earlier codenames as time goes on.

Also unlike Ubuntu's alphabetical naming scheme, the number approach doesn't have any overflow issues (which isn't as big of an issue anyway because Debian's provides new releases every 2 years instead of 6 monthly).

Yep, the United States government gaining the ability to directly block the licensing of ARM reference designs from companies like Huawei's HiSilicon (and the fabless chip designers such as Rockchip) is a VERY big deal. It's a very different situation to the US government having to pressure Japan's SoftBank, UK's ARM Holdings (or their respective governments).

Sorry, I forgot that typical grub.cfg contains the root partition's UUID (and at least historically, the partition device node). While it is possible to configure GRUB to scan for a root partition rather than using a UUID, this is less secure (eg, GRUB residing on your hard drive could then accidentally select your root partition residing on a USB stick containing Linux live media).

Good point that in general, the operating system vendor does not know the grub.cfg on an installed system, and that an attacker with direct access to the ESP can modify the files that are present there.

A static grub.cfg that selects "the Linux root partition is the first partition on the device on which this GRUB bootloader is installed on" would work. I don't believe GRUB supports this kind of behavior (maybe it should). It seems worthwhile and possible to design a mechanism where a simple grub.cfg can be signed by the operating system vendor. Disabling the ability to arbitrarily modify kernel boot options on a general purpose operating system is not a big deal, and could be mitigated with extra GRUB boot menu items.

With the sole exception of one bootable tool vendor who added custom code to perform a signature verification of the grub.cfg config file in addition to the signature verification performed on the GRUB2 executable, all versions of GRUB2 that load commands from an external grub.cfg configuration file are vulnerable.

Perhaps the ability to sign grub.cfg should be added to GRUB2, and this feature should be enabled by default.

Though this would mean rather than allowing users to enter arbitrary kernel boot options (and being able to leverage buffer overflow exploits), a bunch of preset menu items would have to be present. Alternatively, this signed grub.cfg can have its boot menu password-protected. (If I recall correctly individual menu items cannot be password protected.)

Lowering the GRUB2 attack surface area is a good idea, so hopefully these suggestions get deeply considered.

It's strange, because Nintendo has such good first-party game development skills, develops entire operating systems for their internet-connected consoles (including security architectures spanning hardware/software).

Even some of Nintendo's top brass have had strong software engineering skills: in the late 1990s, during the development of Pokemon Gold & Silver, the team was struggling so future Nintendo President Satoru Iwata developed and implemented a compression algorithm.

The skills are certainly there.

Due to decades of Deng Xiaoping's One Child Policy, China is a slow motion demographic car crash that's impossible to stop. China will "get old before it gets rich", and the days of 6% growth aren't coming back.

I recommend anyone interested in geopolitics and the world over the next 30 years to watch this lecture: https://www.youtube.com/watch?v=_AvNT3vyzr0

It's the best overview of the future wealth and strength of brutal Chinese dictatorship that I've come across.