Last time, we looked at the legacy icons in progman.exe. But what about moricons.dll?

Here’s a table of the icons that were present in the original Windows 3.1 moricons.dll file (in file order) and the programs that Windows used the icons for. As with the icons in progman.exe, these icons are mapped from executables according to the information in the APPS.INF file.

↫ Raymond Chen

These icons age like a fine wine. They’re clear, well-designed, easy to read, and make extraordinary good use of the limited amount of available pixels. Icons from Mac OS, BeOS, OS/2, and a few others from the same era also look timeless, and I wish modern designers learned a thing or two from these.

You may not have heard of the “Transparency & Consent Framework”, but you’ve most likely interacted with it, probably on a daily basis. The TCF is used by 80% of the internet to obtain “consent” from users to collect their data and share it among advertisers – you know, the cookie popups. In a landmark EU ruling yesterday, the TCF has been declared to violate the GDPR, making it illegal.

For seven years, the tracking industry has used the TCF as a legal cover for Real-Time Bidding (RTB), the vast advertising auction system that operates behind the scenes on websites and apps. RTB tracks what Internet users look at and where they go in the real world. It then continuously broadcasts this data to a host of companies, enabling them to keep dossiers on every Internet user. Because there is no security in the RTB system it is impossible to know what then happens to the data. As a result, it is also impossible to provide the necessary information that must accompany a consent request.

↫ Irish Council for Civil Liberties

It’s no secret that cookie consent popups do not actually comply with the GDPR, and that they are not even necessary if you simply don’t do any cross-site sharing of personal information. It seems that this ruling confirms this in a legal sense, forcing the advertising industry to come up with a new, better system. On top of that, every individual company that participated in this scheme is now liable for fines and damages.

Complaints coordinated by Johnny Ryan, Director of Enforce at the Irish Council for Civil Liberties, prompted the ruling. He said:

Today’s court’s decision shows that the consent system used by Google, Amazon, X, Microsoft, deceives hundreds of millions of Europeans. The tech industry has sought to hide its vast data breach behind sham consent popups. Tech companies turned the GDPR into a daily nuisance rather than a shield for people.

↫ Irish Council for Civil Liberties

The problem here is not so much the clarity of applicable laws and regulations, but the cost and effectiveness of enforcement. If it takes years of expensive and complex legal proceedings to bring a company that violates the GDPR to heel, is it really an effective legal framework? Especially when you take into account just how many companies, big and small, there are that violate the GDPR?

OSNews uses a cookie popup and displays advertising, something we have to do to gain a little bit of extra income – but I’m not happy about it. Our ads don’t provide us with much income, perhaps about €150-200, but that’s still a decent enough chunk of our income pie that we need it. I would greatly prefer we turn off these ads altogether, but in order to be able to afford that, we’d need to up our Patreon income. OSNews Patreons get an ad-free version of OSNews.

That’s a long and slow process, especially with the current economic uncertainty making people reconsider their expenses. Disabling our ads altogether for everyone once we’re fully reader-funded is still my end goal, but until the world around us settles down a bit, that’s a little while off. If you want to speed this process up – you can become an OSNews Patreon and enjoy an ad-free OSNews today.

Accessibility in the software world is a problem in general, but it’s an even bigger problem on open source desktops, as painfully highlighted by this excellent article detailing the utterly broken state of accessibility on Linux. Reading the article is soul-crushing as it starts to dawn on you just how bad the situation really is for those among us who require accessibility features, making it virtually impossible for them to switch to Linux.

This obviously has to change, and it just so happens that both on the GTK/GNOME and KDE side, recent work on accessibility has delivered some valuable results. Starting with GTK and GNOME, the framework has recently merged the AccessKit backend with GTK 4.18, which enables accessibility features when running GTK applications on Windows and macOS. On Linux, GTK still defaults to at-spi, but I’m sure this will change eventually too.

Another major improvement are the special keyboard shortcuts normally provided by the screen reader Orca. Support for these was in the works for a while but incomplete, but now this work has been completed, and the new shortcuts ship as part of GNOME 48. Accessibility support for GNOME Web has been greatly improved as well, and Elevado is a new tool that shows you what applications expose on the a11y bus. There’s a ton additional, smaller changes too.

On the KDE side, a number of accessibility improvements have been implemented as part of the project’s goal to improving input handling. You can now use the numerical pad’s arrow keys to move the mouse cursor, there’s a new 3-finger gesture to invoke the desktop zoom accessibility feature, keyboard navigation in general has been improved in a wide variety of places in KDE, and a whole bunch more improvements. In addition, a number of financial grants have been given to developers working on accessibility in KDE, such as a project to make file management-related features – think open/save dialogs, Dolphin, and so on – fully accessibly, and projects to make touchpad and screen gestures fully customisable.

Accessibility is never really “done” or “perfect”, but there’s definitely an increasing awareness among the two major open source desktops of just how important it is. A few confounding factors – like the switch to Wayland or the complicated history of audio on Linux – have actually hurt accessibility, and it’s only now that things are starting to look up again. However, as anyone with reduced vision or auditory problems can tell you, Linux and the open source desktop still has a very long way to go.

Following rumors, Xiaomi today announced that it will launch its very own chip for smartphones later this month. The “XRING 01” is a chip that the company has apparently been working on for over 10 years now.

Details about the chip are scarce so far, but GizmoChina points to recent leaks that suggest the chip is built on a 4nm process through TSMC. The chip supposedly has a 1+3+4 layout and should lag just a bit behind Snapdragon 8 Elite and Dimensity 9400 in terms of raw horsepower, sounding familiar to Google’s work with Tensor chips.

↫ Ben Schoon at 9To5Google

I like this. Having almost every Android device use Qualcomm’s chips is not good for fostering competition, and weakens Android OEMs’ bargaining position. If we have more successful SoC makers, consumers will not only gain access to a wider variety of chips that may better suit their needs, it will also force Qualcomm to lower its prices, compete better, or both. Everybody wins.

Well, except Qualcomm, I guess.

I don’t know anything about hiring processes in Silicon Valley, or about hiring processes in general since I’ve always worked for myself (and still do, running OSNews, relying on your generous Patreon and Ko-Fi support), so when I ran into this horror story of applying for a position at a Silicon Valley startup, I was horrified. Apparently it’s not unheard of – it might even be common? – to ask applicants for a coding position to develop a complex application, for free, without much guidance beyond some vague, generic instructions?

In this case, the applicant, Jose Vargas, was applying for a position at Kagi, the search startup with the, shall we say, somewhat evangelical fanbase. After applying, he was asked to develop a complete e-mail client, either as a TUI/CLI or a web application that can view and send emails, using a fake or a real backend, which can display at least plaintext e-mails. None of this was going to be paid labour, of course.

Vargas started out by sending in a detailed proposal of what he was planning to create, ending with the obvious question what kind of response he’d get if he actually implemented the detailed proposal. He got a generic response in return, without an answer to that question, but he set out to work regardless. In the end, it took him about a week to complete the project and send it in. He eventually received a canned rejection notice in response, and after asking for clarification the hiring manager told him they wanted something “simpler and stronger”, so he didn’t make the cut.

I’m not interested in debating whether or not Vargas was suited for the position, or if the unpaid work he sent in was any good. What I do want to talk about, though, is the insane amount of unpaid labour applicants are apparently asked to do in Silicon Valley, the utter lack of clear and detailed instructions, and how the hiring manager didn’t answer the question Vargas sent in alongside his detailed proposal. After all, the hiring manager could’ve saved everyone a ton of time by letting Vargas know upfront the proposal wasn’t what Kagi was looking for.

Everything about this feels completely asinine to me. As a (former) translator, I’m no stranger to having to do some work to give a potential client an idea of what my work looks like, but more than half a page of text to translate was incredibly rare. Only on a few rare occasions did a prospective client want me to translate more than that, and in those cases it was always as paid labour, at the normal, regular rate. For context, half a page of text is less than half an hour of work – a far cry from a week’s worth of unpaid labour.

I’ve read a ton of online discourse about this particular story, and there’s no clear consensus on whether or not Vargas’ feelings are justified. Personally, I find the instructions given by Kagi overly broad and vague, the task of creating an email client to be overly demanding, and the canned (“AI”?) responses by the hiring manager insulting – after sending in such a detailed proposal, it should’ve been easy for a halfway decent hiring manager to realise Vargas might not be a good fit for the role, and tell him so before he started doing any work.

Kagi is fully within its right to determine who is and is not a good fit for the company, and who they hire is entirely up to them. If such stringent, demanding hiring practices are par for the course in Silicon Valley, I also can’t really fault them for toeing the industry line. The hiring manager’s behaviour seems problematic, but everyone makes mistakes and nobody’s perfect. In short, I’m not even really mad at Kagi specifically here.

However, if such hiring practices are indeed the norm, can I, as an outsider, just state the obvious?

What on earth are you people doing to each other over there in Silicon Valley?

Is this really how you want to treat potential applicants, and how you, yourself, want to be treated? Imagine if a someone applies to be a retail clerk at a local supermarket, and the supermarket’s hiring manager asks the applicant to work an entire week in the store, stocking shelves and helping shoppers, without paying the person any wages, only to deny their application after the week of free labour is over? You all realise how insane that sounds, right?

Why not look at a person’s previous work, hosted on GitHub or any of its alternatives? Why not contact their previous employers and ask about their performance there, as happens in so many other industries? Why, instead of asking someone to craft an entire email client, don’t you just give them a few interesting bugs to look at that won’t take an entire week of work? Why not, you know, pay for their labour if you demand a week’s worth of work? I’m so utterly baffled by all of this.

Y’all developers need a union.

How do you get email to the folks without computers? What if the Post Office printed out email, stamped it, dropped it in folks’ mailboxes along with the rest of their mail, and saved the USPS once and for all?

And so in 1982 E-COM was born—and, inadvertently, helped coin the term “e-mail.”

↫ Justin Duke

The implementation of E-COM was awesome. You’d enter the messages on your computer, send it to the post office using a TTY or IBM 2780/3789 terminals, to Sperry Rand Univac 1108 computer systems at one of 25 post offices. Postal staff would print the messages and send them through the regular postal system to their recipients. The USPS actually tried to get a legal monopoly on this concept, but the FCC fought them in court and won out.

E-COM wasn’t the breakout success the USPS had hoped for, but it did catch on in one, unpleasant way: spam. The official-looking E-COM enevelopes from the USPS were very attractive to junk mail companies, and it was estimated that about six companies made up 70% of the total E-COM volume of 15 million messages in its second year of operation.

The entire article is definitely recommended reading, as it contains a ton more information about E-COM and some of the other attempts by USPS to ride the coattails of the computer and internet revolution, including the idea to give every US resident an @.us e-mail address. Wild.

Let’s dive into a peculiar bug in iOS. And by that I mean, let’s follow along as Guilherme Rambo dives into a peculiar bug in iOS.

The bug is that, if you try to send an audio message using the Messages app to someone who’s also using the Messages app, and that message happens to include the name “Dave and Buster’s”, the message will never be received.

↫ Guilherme Rambo

As I read this first description of the bug, I had no idea what could possibly be causing this. However, once Rambo explained that every audio message is transcribed by Apple into a text version, I immediately assumed what was going on: that “and” is throwing up problems because the actual name of the brand is stylised with an ampersand, isn’t it? It’s always DNS HTML, isn’t it?

Yes. Yes it is.

MessagesBlastDoorService uses MBDXMLParserContext (via MBDHTMLToSuperParserContext) to parse XHTML for the audio message. Ampersands have special meaning in XML/HTML and must be escaped, so the correct way to represent the transcription in HTML would have been "Dave & Buster's". Apple’s transcription system is not doing that, causing the parser to attempt to detect a special code after the ampersand, and since there’s no valid special code nor semicolon terminating what it thinks is an HTML entity, it detects an error and stops parsing the content.

↫ Guilherme Rambo

It must be somewhat of a relief to programmers and developers the world over that even a company as large and filled with talented people as Apple can run into bugs like this.

Following on from OpenBSD/arm64 on QEMU, it’s not always practical to compile userland software or a new kernel on some systems, particularly small SoCs with limited space and memory – or indeed QEMU, in fear of melting your CPU.

There are two scenarios here – the first, if you are looking for a standard cross-compiler for Aarch64, and the second if you want an OpenBSD-specific environment.

↫ Daniel Nechtan

Exactly what it says on the tin.

The title is a lie. This isn’t brief at all.

Picture the keypad of a telephone and calculator side by side. Can you see the subtle difference between the two without resorting to your smartphone? Don’t worry if you can’t recall the design. Most of us are so used to accepting the common interfaces that we tend to overlook the calculator’s inverted key sequence. A calculator has the 7–8–9 buttons at the top whereas a phone uses the 1–2–3 format.

Subtle, but puzzling since they serve the same functional goal — input numbers. There’s no logical reason for the inversion if a user operates the interface in the same way. Common sense suggests the reason should be technological constraints. Maybe it’s due to a patent battle between the inventors. Some people may theorize it’s ergonomics.

With no clear explanation, I knew history and the evolution of these devices would provide the answer. Which device was invented first? Which keypad influenced the other? Most importantly, who invented the keypad in the first place?

↫ Francesco Bertelli and Manoel do Amara

Sometimes, you come across articles that are one-of-a-kind, and this is one of them. Very few people would go to this length to document such a particular thing most people find utterly insignificant, but luckily for us, Francesco Bertelli and Manoel do Amara went all the way with this one. If you want to know anything about the history of the numerical pad and its possibly layouts, this is the place to go.

What I’ve always found fascinating about numerical pads is how effortless the brain can switch between the two most common layouts without really batting an eye. Both layouts seem so ingrained in my brain that it feels like there’s barely any context-switching involved, and my fingers just effortlessly flow to the correct numbers. Considering numbers tend to confuse me, I wouldn’t have been at all surprised to find myself having issues switching between the two layouts.

What makes this even more interesting is when I consider the number row on the keyboard – you know, 1 through 0 – because there I do tend to have a lot of issues finding the right numbers. I don’t mean it takes seconds or anything like that, but I definitely experience more hiccups working with the number row than with a numerical keypad of either layout.

We’re looking at an article from 2007 here, but I still think it’s valuable and interesting, especially from a historical perspective.

I first started working on the UNIX file system with Bill Joy in the late 1970s. I wrote the Fast File System, now called UFS, in the early 1980s. In this article, I have written a survey of the work that I and others have done to improve the BSD file systems. Much of this research has been incorporated into other file systems.

↫ Marshall Kirk McKusic

Variants of UFS are still the default file system in at least NetBSD and OpenBSD, and it’s one of the two default options in FreeBSD (alongside ZFS). In other words, this article, and the work described therein, is still relevant to this very day.

Notifications in Chrome are a useful feature to keep up with updates from your favorite sites. However, we know that some notifications may be spammy or even deceptive. We’ve received reports of notifications diverting you to download suspicious software, tricking you into sharing personal information or asking you to make purchases on potentially fraudulent online store fronts.

To defend against these threats, Chrome is launching warnings of unwanted notifications on Android. This new feature uses on-device machine learning to detect and warn you about potentially deceptive or spammy notifications, giving you an extra level of control over the information displayed on your device.

↫ Hannah Buonomo and Sarah Krakowiak Criel on the Chromium Blog

So first web browser makers introduce notifications, a feature nobody asked for and everybody hates, and now they’re using “AI” to combat the spam they themselves enabled and forced onto everyone? Don’t we have a name for a business model where you purport to protect your clients from threats you yourself pose?

Turning off notifications is one of the first things I do after installing a browser. I do not ever want any website sending me a notification, nor do I want any of them to ask me for permission to do so. They’re such an obvious annoyance and massive security threat, and it’s absolutely mindboggling to me we just accept them as a feature we have to live with. I genuinely wish browsers like Firefox, which claim to protect your privacy, would just have the guts to be opinionated and rip shit features like this straight out of their browser.

Using “AI” to combat spam notifications instead of just turning notifications off is peak techbro.

A few months ago I shared my Swift SDK for Darwin, which allows you to build iOS Swift Packages on Linux, amongst other things. I mentioned that a lot of work still needed to be done, such as handling codesigning, packaging, and bundling.

I’m super excited to share that we’ve finally reached the point where all of these things are now possible with cross-platform, open source software. Enter, xtool!

[…]

This means it’s finally possible to build and deploy iOS apps from Linux and Windows (WSL). At the same time, xtool is SwiftPM-based and fully declarative, which means you can also use it to replace Xcode on macOS for building iOS software!

↫ kabiroberai

While this is obviously an impressive piece of engineering that’s taken countless years to fully put together, the issue this doesn’t address are Apple’s licensing terms when it comes to Xcode and development for Apple’s platforms. The Apple Developer Program License Agreement clearly forbids installing Xcode and the Apple SDK on non-Apple branded devices, and as this new xtool requires you download Xcode.xip and use it, it seems it violates these terms.

Now, as far as I’m concerned, these terms are idiotic and should be 100% illegal, but if you’re an Apple developer who relies on your Apple developer account to make money, using a tool like this definitely has the potential to put your developer account at risk. For experimentation, sure, this is great, but for any official work I would be quite weary until Apple makes some sort of statement about the matter, which is highly unlikely to happen.

Perhaps the courts can, at some point, have a say here – especially in the EU – but even then, Apple can always find or manufacture some reason to terminate your account if they really want to. If you want to develop on your own terms, perhaps developing for Apple platforms is not what you should be doing.

John Siracusa, one third of the excellent ATP podcast, developer of several niche Mac utilities, and author of some of the best operating system reviews of all time, has called for Apple’s CEO, Tim Cook, to step down. Now, countless people call for Tim Cook to stand down all the time, but when someone like Siracusa, an ardent Mac user since the release of the very first Macintosh and a staple of the Apple community, makes such a call, it carries a bit more weight.

His main argument is not particularly surprising to anyone who’s been keeping tabs on the Apple community, and the Apple developer community in particular: Apple seems to no longer focus on making great products, but on making money. Every decision made by Apple’s leadership team is focused solely on extracting as much money from consumers and developers, instead of on making the best possible products.

The best leaders can change their minds in response to new information. The best leaders can be persuaded. But we’ve had decades of strife, lawsuits, and regulations, and Apple has stubbornly dug in its heels even further at every turn. It seems clear that there’s only one way to get a different result.

In every healthy entity, whether it’s an organization, an institution, or an organism, the old is replaced by the new: CEOs, sovereigns, or cells. It’s time for new leadership at Apple. The road we’re on now does not lead anywhere good for Apple or its customers. It’s springtime, and I’m choosing to believe in new life. I swear it’s not too late.

↫ John Siracusa

I reached this same point with Apple a long, long time ago. I was an ardent Mac user during the PowerPC G4 and G5 days, lasting into the early Intel days. However, as the iPhone and related services took over as Apple’s primary source of income, I felt that Mac OS X, which I once loved and enjoyed so much, started to languish, and it’s been downhill for Apple’s desktop operating system ever since. Whenever I have to help my parents with their computers – modern M1 and M2 Macs – I am baffled and saddened by just how big of a convoluted, disjointed, and unintuitive mess macOS has become.

I long ago stopped caring about whatever products Apple releases or updates, because I feel like as a user who genuinely cares about his computing experience, Apple simply doesn’t make products for me. I’m not sure replacing Tim Cook with someone else will really change anything about Apple’s priorities; in the end, it’s a publicly traded corporation that thinks it needs to please shareholders, and a focus on great products instead of money isn’t going to help with that.

Apple long ago stopped being the beleaguered company many of its most ardent fans still seem convinced that it is, and it’s now one of those corporate monoliths that can make billions more overnight by squeezing just a bit more out of developers or users, regardless of what that squeezing does to the user experience. Apple is still selling more devices than ever, and it’s still raking in more gambling gains through digital slot machines for children, and as long as that’s the case, replacing Tim Cook won’t do a goddamn thing.

The team that makes Cockpit, the popular server dashboard software, decided to see if they could improve their PR review processes by adding “AI” into the mix. They decided to test both sourcey.ai and GitHub Copilot PR reviews, and their conclusions are damning.

About half of the AI reviews were noise, a quarter bikeshedding. The rest consisted of about 50% useful little hints and 50% outright wrong comments. Last week we reviewed all our experiences in the team and eventually decided to switch off sourcery.ai again. Instead, we will explicitly ask for Copilot reviews for PRs where the human deems it potentially useful.

This outcome reflects my personal experience with using GitHub Copilot in vim for about 1.5 years – it’s a poisoned gift. Most often it just figured out the correct sequence of ), ], and } to close, or automatically generating debug print statements – for that “typing helper” work it was actually quite nice. But for anything more nontrivial, I found it took me more time to validate the code and fix the numerous big and subtle errors than it saved me.

↫ Martin Pitt

“AI” companies and other proponents of “AI” keep telling us that these tools will save us time and makes things easier, but every time someone actually sits down and does the work of testing “AI” tools out in the field, the end results are almost always the same: they just don’t deliver the time savings and other advantages we’re being promised, and more often than not, they just create more work for people instead of less. Add in the financial costs of using and running these tools, as well as the energy they consume, and the conclusion is clear.

When the lack of effectiveness of “AI” tools our in the real world is brought up, proponents inevitably resort to “yes it sucks now, but just you wait on the next version!” Then that next version comes, people test it out in the field again, and it’s still useless, and those same proponents again resort to “yes it sucks now, but just you wait on the next version!”, like a broken record. We’re several years into the hype, and that mythical “next version” still isn’t here.

We’re several years into the “AI” hype, and I still have seen no evidence it’s not a dead end and a massive con.