There are early signs that some European companies and governments are souring on their use of American cloud services provided by the three so-called hyperscalers. Between them, Google Cloud, Microsoft Azure, and Amazon Web Services (AWS) host vast swathes of the Internet and keep thousands of businesses running. However, some organizations appear to be reconsidering their use of these companies’ cloud services—including servers, storage, and databases—citing uncertainties around privacy and data access fears under the Trump administration.
“There’s a huge appetite in Europe to de-risk or decouple the over-dependence on US tech companies, because there is a concern that they could be weaponized against European interests,” says Marietje Schaake, a nonresident fellow at Stanford’s Cyber Policy Center and a former decadelong member of the European Parliament.
I’ve seen a lot of news like this recently from US-based media outlets. As someone living and working in Germany for a German company, I find it particularly interesting that I haven’t heard anything about this elsewhere, not even at my current position where AWS is heavily used. There has been no discussion about this whatsoever.
That isn’t to say that it isn’t happening. The article does indeed cite a few examples such as the Dutch government trying to move some of their services to European-based providers but I still have yet to see any difference in my own experience.
Moving clouds is a messy, expensive business if you are heavily invested in one of the major American providers. I suspect that most companies would have to have a huge financial or political incentive to invest the time and money to do so. A few barbs traded by politicians isn’t going to be enough in most cases.
This is a post that will most certainly betray my age in that I fondly remember the release of Mac OS X 10.6 Snow Leopard. The previous year’s release, 10.5 Leopard, was a significant upgrade in visuals and features after 10.4 Tiger’s many years of service. Unfortunately, with large upgrades come large amounts of bugs. While I can’t remember Leopard being unstable, I do remember that Snow Leopard made the system feel much more stable and polished which was exactly the point of the release. No new features, just more stability.
That said, 9to5Mac raises the question as to whether another Snow Leopard-like release is something that the Apple community needs:
The last few days have been very busy when it comes to Apple news. That’s because the company has confirmed that the new Siri experience has been delayed while sources suggest that the new features promised at last year’s WWDC won’t be ready any time soon. Given everything that’s going on at Apple recently, there’s one thing that could really help: another Snow Leopard.
Frankly, I think we are definitely lacking a good stability release. As someone who relies on their Macs, iPhone and iPad every single day for work and play, it is crucial to me that the operating system and its accompanying software be as unproblematic and stable as possible.
Mozilla has recently had a lot of blowback about several recent changes they’ve made to Firefox. They have introduced a Terms of Service and have updated their privacy policy to include vague language about data collection. I won’t go into detail here though, so if you don’t know what’s going on, this is a great summary:
As a reaction to this video, however, Ryan Sipes, a member of the Thunderbird team, went on video to clarify what the situation is. This video is definitely worth watching if you are interested in what is going on:
I tend to give Mozilla the benefit of the doubt in this situation. They were quick to react to the feedback they received and since they are such a prominent name in the open source community, their every move will be continued to be heavily scrutinized online which I’m absolutely certain they are aware of.
In an effort to speed up TypeScript compilation, Microsoft has decided to rewrite the compiler to be a native application. There are, of course, a number of languages they could have chosen for this endeavor, but this is why they chose Go:
Language choice is always a hot topic! We extensively evaluated many language options, both recently and in prior investigations. We also considered hybrid approaches where certain components could be written in a native language, while keeping core typechecking algorithms in JavaScript. We wrote multiple prototypes experimenting with different data representations in different languages, and did deep investigations into the approaches used by existing native TypeScript parsers like swc, oxc, and esbuild. To be clear, many languages would be suitable in a ground-up rewrite situation. Go did the best when considering multiple criteria that are particular to this situation, and it’s worth explaining a few of them.
By far the most important aspect is that we need to keep the new codebase as compatible as possible, both in terms of semantics and in terms of code structure. We expect to maintain both codebases for quite some time going forward. Languages that allow for a structurally similar codebase offer a significant boon for anyone making code changes because we can easily port changes between the two codebases. In contrast, languages that require fundamental rethinking of memory management, mutation, data structuring, polymorphism, laziness, etc., might be a better fit for a ground-up rewrite, but we’re undertaking this more as a port that maintains the existing behavior and critical optimizations we’ve built into the language. Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable.
Go also offers excellent control of memory layout and allocation (both on an object and field level) without requiring that the entire codebase continually concern itself with memory management. While this implies a garbage collector, the downsides of a GC aren’t particularly salient in our codebase. We don’t have any strong latency constraints that would suffer from GC pauses/slowdowns. Batch compilations can effectively forego garbage collection entirely, since the process terminates at the end. In non-batch scenarios, most of our up-front allocations (ASTs, etc.) live for the entire life of the program, and we have strong domain information about when “logical” times to run the GC will be. Go’s model therefore nets us a very big win in reducing codebase complexity, while paying very little actual runtime cost for garbage collection.
We also have an unusually large amount of graph processing, specifically traversing trees in both upward and downward walks involving polymorphic nodes. Go does an excellent job of making this ergonomic, especially in the context of needing to resemble the JavaScript version of the code.
Acknowledging some weak spots, Go’s in-proc JS interop story is not as good as some of its alternatives. We have upcoming plans to mitigate this, and are committed to offering a performant and ergonomic JS API. We’ve been constrained in certain possible optimizations due to the current API model where consumers can access (or worse, modify) practically anything, and want to ensure that the new codebase keeps the door open for more freedom to change internal representations without having to worry about breaking all API users. Moving to a more intentional API design that also takes interop into account will let us move the ecosystem forward while still delivering these huge performance wins.
As the first comment in the discussion points out, it’s strange that Microsoft didn’t choose C# instead of Go but at the same time, I suspect it has to do with the points they made about keeping with a similar codebase structure and coding patterns for the sake of an easier and quicker port.
In my opinion, it’s interesting that they are choosing to rewrite the TypeScript script compiler at all. I understand that they want it to be faster which would be great for large frontend projects using TypeScript, but for backend Node applications, the TypeScript compiler may soon become superfluous since Node 23 includes native support for running TypeScript files.
It’s almost been 20 years since I started my first blog. The year was 2006 when I signed up for my first blog on WordPress.com. I had had a personal website since 1998, I had mostly just added random stuff to it that didn’t have any consistent structure or content and as such could certainly not be considered to be a blog by any stretch of the imagination.
So if I don’t consider my personal website to be a blog, what exactly is a blog?
A blog is one of those things that people just seem to know what it is when they see it, but that wasn’t enough for the Harvard Law School. In 2003, when blogs (or weblogs as they were called at the time) were still a new concept, an article was posted to their website that attempted to define what exactly a blog was. While the article is 22 years old, I still think the definition stands.
Technically, what is a weblog?
Now on to the technical features and a definition only a mathematician could love.
A weblog is a hierarchy of text, images, media objects and data, arranged chronologically, that can be viewed in an HTML browser.
There’s a little more to say. The center of the hierarchy, in some sense, is a sequence of weblog “posts” — explained below — that forms the index of the weblog, that link to all the content in sequence.
What is a weblog post?
A weblog post has three basic attributes: title, link and description. All are optional. Some weblogs only have descriptions. Others always have all three. On my own weblog, Scripting News, all items have descriptions, a few have titles, and most have links, some have several links. Generally, a title cannot contain markup, but the description can.
Most weblog tools require titles. Manila is fairly unique in not requiring them. The tradeoff is simplicity vs flexibility. It’s simpler from a user interface standpoint to require the presence of all three basic attributes, but writers can find this limiting.
If one of the basic attributes is optional it’s the link. In that case the title of the post is often linked to a permalink for the item (see below).
Most weblog posts are short, a paragraph or two. Some weblog tools provide for longer articles or stories, often by including a place for a summary in the form for a weblog post. If available, there should also be an option for only including the summary in the RSS feed for the weblog.
The article goes a lot more into detail about what a blog actually is and what it consists of. I found this to be interesting because I have kept various blogs using different platforms for so long but never actually took the time to stop and think about what makes a blog a blog rather than just any old other website.
As an interesting side note, the author of the original article, Dave Winer, still writes daily in his blog that he mentions above.
I somewhat recently ran into this screenshot of a rant that Linus Torvalds went on about C++ and why he thinks C is the better programming language. I usually don’t care much for the drama because I think each programming language has its purpose and there will always be developers who love them and hate them. However, what I did find interesting about this particular rant is that it not only came from a very well-respected developer who has a deep understanding of low-level languages, but also that his arguments fly in the face of conventional, modern software architecture.
What I mean by that is that he argues against object-oriented programming, class inheritance and other core principles of most modern languages. I am, of course, aware that his rant is nearly twenty years old but even then, those were the important principles in software architecture.
AI-generated image of shelves full of paper, books and floppy disks
I recently ran into a blog post on another blog titled “No Data Lasts Forever.” As the name implies, it discusses the longevity of the existence of not only digital data but also other forms such as stone, papyrus and paper.
I found the post interesting and worth writing about on my blog because it is a topic I have also given a lot of thought into myself. One of my degrees is in history, and using, archiving and preserving old documents is a large part of a historian’s job, so I do have some experience in that area. On top of that, I produce a lot of written content between all of my various blogs, have composed and recorded several music albums, and have also produced a ton of code in my free time.
All of this has driven me to think about how long it will last. The content I produce is almost exclusively digital and of course, no one really knows how long digital data can be preserved. Data corruption is always a looming specter while the largest threat is probably the availability of software and technology to access that data.
Most programs use proprietary formats to save the data they produce. This means that once those programs are no longer supported or are no longer able to be run, the potential for data loss is massive.
So how can you ensure your digital data will last as long as possible? That is a difficult question to answer as no response can be a guarantee. However, there are a few things you can do to make sure it’s at least as accessible for as long as possible.
Attempting to Preserve Digital Data
The first item to mention is to make your data as universally accessible as possible. What I mean by this is that a person should be able to open it on any platform using a wide range of programs. A great example of this is text files. It doesn’t matter if the extension is .txt, .html, .md or any other format, these files can be opened on any platform using a huge variety of programs.
Plain text is also so widespread that the likelihood of it not working in the future is minimal. There are other formats that you could probably lump into that category as well, but they may not have quite the same ultra-high chances. Examples are Microsoft Word documents (.doc/.docx), PDFs (.pdf), various image formats (.jpeg/.jpg, .png, .gif), etc. These are ubiquitous in modern computing and also openable by a plethora of different applications on a variety of platforms. The risk though is that there might be compatibility problems with, say, opening a .docx file in LibreOffice which means the original might not be perfectly preserved. Even a new version of Microsoft Word itself might not be able to open and older file properly anymore.
It also goes without saying that you need to make sure you have backups: onsite as well as offsite. Those backups will help with preservation for anyone that has access to them, but if you are creating works that you want available to the public (such as this blog), then it makes sense to also have public backups so that the content will continue to be accessible in the future.
I have done exactly that with my blogs by creating a script that exports the content using the WordPress API, converts it to Markdown (plain text) and pushes it to a public repository on GitHub. There is one repository per blog and I have the backup script running once every evening. You can read more about it in the post I wrote about.
The point I am trying to make with this though is that GitHub will most likely be around a lot longer than this blog which is self-hosted on a rented virtual server. I also intend to push the content to other git hosting services such as GitLab, but haven’t gotten around to it yet.
Of course, I am under no illusion that GitHub, GitLab or any other company is going to be around forever which leaves the question: What happens when they’ve all shut down? Well, the bad news is that if you want something to be public, you have to rely on someone to host it. That’s especially true for the long-run. Even sites like the Internet Archive whose sole purpose is to, well, archive the internet probably won’t be around for very long in the grand scheme of things.
Other Options
So, if you can’t entirely rely on someone else to host your content forever, how do you preserve it for as long as possible? Well, for one, you’ll probably have to forego having it archived publicly. You can certainly make as many copies as possible on various types of media such as CDs or DVDS, but even those decay in only a matter of decades which really isn’t very long at all if you consider the fact that we still have hieroglyphics carved into stone that are thousands of years old.
I’m afraid the only answer I can think of to that question is to just simply print it out. Paper doesn’t last forever either, but it is at least a known quantity and, if taken care of properly, can last for centuries. We still have plenty of paper documents that date back to the dark ages and beyond.
Is it realistic to print everything out? Probably not. I’m certainly not going to bother doing that with my blogs and even if I did, it would only be for the posts that I consider to be the best. I do, however, keep a daily journal which I always have a hard copy of. Some years I’ve handwritten it in a notebook while others, I’ve typed it and printed it out at the end of each year. The journal isn’t just intended for me though, but also for my son, his children, their children, etc. That’s why having a hardcopy of it is critical for me.
Conclusion
Digital data preservation is a very difficult subject and we have yet to see how long we can actually preserve it without corruption, media failures, software incompatibility and so on. We can already measure it to an extent in decades, but what about centuries or even millennia? We just can’t know that yet.
There is a lot of interest in the subject though as more and more data becomes exclusively digital. Government and corporate entities certainly have a huge interest in preserving and archiving their digital data for as long as possible which is why I think we will continue to see improvements in this area.
Well, at the beginning of February, Raymond published another post on the same Microsoft blog about comments he had received about his original post wondering whether the developers responsible for creating the Windows 95 setup had forgotten about the fact that MS-DOS could do basic GUI interfaces. The idea, of course, was that since MS-DOS could do basic GUI interfaces, the Windows 3.1 and Windows 95 parts of the setup were redundant.
Unsurprisingly, Raymond makes quite a few good points in his response:
One of the reactions to my discussion of why Windows 95 setup used three operating systems (and oh there were many) was my explanation that an MS-DOS based setup program would be text-mode. But c’mon, MS-DOS could do graphics! Are you just a bunch of morons?
Yes, MS-DOS could do graphics, in the sense that it didn’t actively prevent you from doing graphics. You were still responsible for everything yourself, though. There were no graphics primitives aside from a BIOS call to plot a single pixel. Everything else was on you, and you didn’t want to use the BIOS call to plot pixels anyway because it was slow. If you wanted any modicum of performance, you had to access the frame buffer directly.
[…]
But the setup program needs more than just pixels. It also wants dialog boxes, so you’ll have to write a window manager to sit on top of your graphics library so you can show dialog boxes with a standard GUI dialog interface, which includes keyboard support for tabbing between elements and assigning hotkeys to fields.
You’ll also have to add support for typing characters in non-alphabetic languages like Japanese. Fortunately, you have a team of folks expert in Japanese input sitting in the Tokyo office working on Windows input methods who can help you out, though the time zone difference between Tokyo and Redmond is going to slow you down.
[…]
Now take a step back and look at what you’re doing. You’re writing an operating system. (Or, if you are being uncharitable, you’re writing an MS-DOS shell.)
An operating system with exactly one application: Windows 95 Setup.
What if I told you that Microsoft already had an operating system that did all the things you are trying to do, and it’s fully debugged, with video drivers, a graphics library, a dialog manager, a scheduler, a protected mode manager, and input methods. And it has a fully staffed support team. And that operating system has withstood years of real-world usage? And Microsoft fully owns the rights to it, so you don’t have to worry about royalties or licensing fees? And it’s a well-known system that even has books written about how to program it, so it’ll be easier to hire new people to join your team, since you don’t have to spend a month teaching them how to code for your new custom Setup UI miniature operating system.
Of course, I’m not going to quote the entire thing here. I can definitely recommend you read through its tongue-in-cheek humor though. It definitely makes a compelling argument for why the Windows 95 setup team did not create a GUI for setup using only MS-DOS.
I am generally a huge fan of Apple’s interfaces. Sometimes they are oversimplified in a way that can be frustrating, but as a rule, their great interface design makes their software pleasant to use in a way other companies or entities can’t hold a candle to.
That said, not everything they do is great and some things can be downright frustrating. One of them is the different placements of the “Stop” button on the homescreen for the built-in timer and alarm functions. When they go off and your iPhone is locked, a fullscreen message will be shown that gives you the option to stop them. The designs are identical except for the fact that the “Stop” button is in opposite positions. That leads to me frequently either repeating the timer or sleeping the alarm rather than turning it off. Those are the other functions offered by the other buttons.
You can see what I mean here:
iPhone Timer Stop Button
iPhone Alarm Stop Button
It’s a small thing, but is still a glaring oversight in an otherwise very consistent UI. Of course, this is complaining at a very high level as an Apple user. If this was a Microsoft or open source project, you would just be happy that the screens look somewhat similar and work properly.
Do you have any pet peeves in any of the interface designs you use on a regular basis? If so, what are they?
A little while ago, I stumbled upon a collection of photos taken from Microsoft’s office in Albuquerque, New Mexico in 1979. At the time, Microsoft was just a small company and it certainly wasn’t clear that they would become the mega-corporation they are now. Even Bill Gates recently said, “I wouldn’t say that I felt comfortable that we were successful until about 1998 or so.”
The photos are fascinating to look at because they provide a glimpse into how it was to work at a computer company during the infancy of the computing industry as we now know it. While most people have computers on their desks, there is certainly a lot more paper than you would see on most programmers’ desks today. Also, several of them were photographed looking at binders and books rather than on their computers which would unlikely be what you would see today.
Overall, it’s interesting to see how times have changed and how thoroughly computers have changed our working environments. At the time same though, it’s interesting to see how little programmers have changed. No suits and ties to be found despite that being the standard office attire at the time!
You can find the photos as well as information about them provided by the photographer at the Web Archives.
Have you ever wondered why the Windows 95 setup seems to consist of three different types of UI? It starts with a typical text-based, MS-DOS UI, then moves onto an interface with buttons and other elements resembling those found in Windows 3.1. Then, in the final stage, you see elements that look like they belong to Windows 95.
As it turns out, that is due to the fact that setup actually runs on three different operating systems: MS-DOS, Windows 3.1 and Windows 95. This seems somewhat excessive, but Raymond Chen, a developer at Microsoft who has worked on Windows for over 30 years, wrote an explanation on one of Microsoft’s official blogs about about the reasoning behind it:
Windows 95 setup could upgrade from three starting points: MS-DOS, Windows 3.1, or Windows 95. (Yes, you could upgrade Windows 95 to Windows 95. You might do this to repair a corrupted system while preserving data.)
One option is to write three versions of Windows 95 setup: One for setting up from MS-DOS, another for setting up from Windows 3.1, and a third for setting up from Windows 95.
This was not a pleasant option because you basically did the same work three times, but implemented separately, so you have to do three times the coding.
A better option is to just write one version of Windows 95 setup and use it for all three starting points. So now you get to choose the platform on which to base your code.
[…]
In the middle is the happy medium: You can have the MS-DOS setup program install a minimal version of Windows 3.1, just barely enough to support what the 16-bit GUI setup program needs.¹ This tiny version is small enough to be copied and installed off a small number of floppy disks. Once that’s done, boot into the tiny version of Windows 3.1 and run the 16-bit GUI setup program.
For anyone interested in retro operating systems or computing history, this is a short but very interesting article about the challenges they faced making Windows 95 installable on as many computers as possible back in the early-to-mid ’90s.
I recently came across an article on Ars Technica that talks about how Google appears to be losing the fight against SEO spam. This is certainly a phenomenon I have noticed not only with Google but also with Bing and Duck Duck Go which is powered by Bing.
If you don’t know what “SEO spam” is, it’s essentially content whose only purpose is to rank high in search results so that people will click on the link and land on a specific website. While the page the user ends up on has to have at least some relevant content to their search query, it is most likely only a fairly useless lure to get them onto the website with the hope that they will click around.
It’s not just you—Google Search is getting worse. A new study from Leipzig University, Bauhaus-University Weimar, and the Center for Scalable Data Analytics and Artificial Intelligence looked at Google search quality for a year and found the company is losing the war against SEO (Search Engine Optimization) spam.
[…]
Overall, the study found that “the majority of high-ranking product reviews in the result pages of commercial search engines (SERPs) use affiliate marketing, and significant amounts are outright SEO product review spam.” Search engines occasionally update their ranking algorithms to try to combat spam, but the study found that “search engines seem to lose the cat-and-mouse game that is SEO spam” and that there are “strong correlations between search engine rankings and affiliate marketing, as well as a trend toward simplified, repetitive, and potentially AI-generated content.”
The practice frustrates me because you search for something, then end up on some random company’s blog that sells shoes but is writing articles about the latest .NET framework or something entirely irrelevant to their actual business. It is simply a means of catching people not searching for shoes and getting them on their website.
Articles like that tend to be shallow, full of repetitious writing (which search engines seem to prefer due to keyword relevancy) and usually don’t contain the information I’m looking for. It’s basically a lose-lose for everyone since I then leave the website pronto.
Alex is a developer, a drummer and an amateur historian. He enjoys being on the stage in front of a large crowd, but also sitting in a room alone, programming something or reading a scary story.
