giamma

Imagine if time travel was possible and we could go back in time and avoid this :-)

It's opensource and AGPL, as long as you do not redistribute it I believe you can fork it and rebuild it.

The blog post says:

"Previously, we obtained the source code for Rocky Linux exclusively from the CentOS Git repository as they recommended. However, this repository no longer hosts all of the versions corresponding to RHEL. Consequently, we now have to gather the source code from multiple sources, including CentOS Stream, pristine upstream packages, and RHEL SRPMs."

Why would you need RHEL SRPMS if the upstream packages contained all the patches and why refer to them as "pristine upstream packages" in the first place?

So long "Upstream First" principle

https://github.com/RedHatOfficial/open-source-participation-...

I am probably looking at it from a too high-level perspective, but the RESTful paradigm was widely adopted in every domain and proved that you can model pretty much any concept as resources, with CRUD primitives and hyperlinks between them.

Wouldn't the same be applicable to files, processes, devices and so on?

Given a complex problem, if there is just one part of it that I fear may not be solvable, then I will look into that part first to figure out if a solution exists and only later into the remaining elements of the problem.

If instead the uncertainty comes just from the "size" of the problem, then I split it into smaller parts that are easier to face, and I look into each of them the bare minimum to be able to confirm that a solution exists. Once I am confident a solution exists for all of the smaller parts and therefore for the whole problem, then I start the actual work.

An APM solution from Apache Foundation that is compatible with OpenTelemetry.

Defender maybe?

Microsoft in 1999 was not the same company it is today and did some very unethical things. For example:

https://www.itprotoday.com/windows-78/ibm-microsoft-warned-p...

Other articles report that computer producers were given Windows "for free" as long as they did not offer nor support OS/2 on their hardware. Microsoft applied this practice for a few years and indeed lost income by giving Windows for free, but it ensured that the regular user never heard of OS/2 and then when IBM gave up the situation changed. Besides, Microsoft would still make money from Office and other products.

I just found out that netlabs.org, an historical provider of free OS/2 software and ports, is still up and running

http://blog.netlabs.org/

https://github.com/bitwiseworks/qtwebengine-chromium-os2

Also, DDE probably earlier than OLE?

I am sorry I can't help you here. The only UI problems I implemented were rather simple, built with IBM VisualAge which had a nice drag&drop visual editor for the screens and dialogs. http://www.os2ezine.com/v1n11/vacpp1.gif

> One of the other concurrent goals at the time was to remove Microsoft code from OS/2. Developers on the team were classified into those who had seen Microsoft code and those who had not. Even seeing the MS code was immediate disqualification from writing anything new, and this was actively enforced.

IBM has always been super cautious about intellectual property. I am an opensource committer at Eclipse Foundation (which was created by IBM) and there is a strict IP review process. A copy/paste from stackoverflow is not allowed.

> I'd always wanted to be excited about OS/2, and the IBM job was about as close as I got. My day to day PC at the job was an ancient (1988-era) PS/2 Model 80, and it ran even the current versions of OS/2 surprisingly well.

I started using OS/2 Warp on a 486 66Mhz with 4GM RAM, it was running pretty smooth for me.

I believe there are still some very specific scenarios in which is used, probably by Banks and in the domain of control theory.

There were news that in early 2000 it was still running the whole Hong Kong airport.

In Italy where I live, up to 2010 if not later, you could still find kiosks for buying railway tickets that were powered by OS/2. These kiosks were quite bulky because they had CRT touch screens! The CRT screens were mounted on a vertical rack inside the kiosk which had two axis, horizontal and vertical, and when you pushed the screen to tap a button the two axis would feel the pressure and would be able to identify the area of the screen that you pushed and to pass coordinates to OS/2 as if you were using a PS/2 mouse. Of course not as precise as a smarphone touchscreen, but those UI used fairly large buttons and everything was working perfectly.

In Italy I think I kept on spotting old ATMs running OS/2 until at least 2015.

I know of a large Bank, this time not Italian, that was still using OS/2 for its tellers probably around 2012. They were using a Web application already, but browsing it via a Firefox port for OS/2 https://wiki.mozilla.org/Ports/os2 They needed to do so because of certain legacy devices (cash dispensers, check printers) which only worked with OS/2.

The hobbes archive still recevies updates and uploads with os/2 software:

https://hobbes.nmsu.edu/ and https://hobbes.nmsu.edu/?path=%2Fpub%2Fnew

Edit: fixed URL

OS/2 was running it's own native programs, usually developed in C/C++ and compiled against it's O.S. API, which were very nicely designed for the time, much cleaner and better organized than most of the competition.

These are not easily portable as they rely on very specific and unique concepts. For example the UI elements (a window, an icon, but also folders and files in the filesystem views) were object oriented concepts in the API and in the UI system (made of WPS - workplace shell and PM - the presentation manager). If you wanted you could subclass the file object and define a new view for it, and all of the user interface would behave accordingly. Similarly you could subclass the folder view and for example add a new status bar, or a box with a shell at the bottom. This was very unique at the time and I believe in part still is today. The system was also in the background constantly tracking UI elements and file system content. So if you created an icon for a file (similar to a Windows shortcut) and then renamed the file, the icon would automatically be aware of the new name, because the file system would fire a "rename event" and the UI would be listening to such events and take appropriate actions. You never had a broken link; if you deleted a file from the command prompt the UI shortcut would be gone as well.

It was also programmable in Object Rexx, an scripting language that would be compiled into bytecode at the first execution of the script. The file system API allowed any program to attach custom attributes to files, and the Rexx runtime would attach the bytecode as a custom attribute to the file so future invocations would skip compilation unless the script was modified. Object Rexx had bindings for most if not all of the operating system APIs, so while Object Rexx interpreters exist for other operating systems, the scripts are hardly portable unless they are trivial.

OS/2 could run MS/DOS and Windows 3.1 program in a compatibility virtual machine. In this case however you would loose multi tasking for those programs because dos and Windows 3.1 did not have multi tasking. Those program would run only when in foreground.

OS/2 could run Java up to Java 1.2 programs.

And due to some volunteer effort there was a quite complete POSIX compatibility layer and a port of GCC which allowed compiling for OS/2 many Unix programs (Apache HTTP for example). There was also a port of XFree available but it was running full screen, so you either used the native UI, or you could switch to a XFree program which first would bring XFree to full screen and then you could work with the program window (of course alt-tabbing back to a native program would do the opposite)

It was very advanced in many ways, for example it supported so called "installable file systems": you could add support for a file system by loading its driver at boot time and when a file system did not support custom attributes, they would be saved in a special hidden file in the root folder. It officially supported HPFS (its own), FAT, JFS, and there existed IFS implementations for Ext2, NTFS and more which were mostly ports from early Linux.

The UI was super customizable, you could have hot corners, multiple virtual desktops, you could individually customize fonts and background of each folder (you simply dragged the font from the front palette to the folder and your preference was recorded in the file system custom attributes together with last size and position of the folder window). Similarly, to change the icon of a program, you had to open preferences and drag and drop the new icon over the previous one, so for many things it had approaches that are similar to those in place in MacOs.

I remember using some old IBM IDE that was implemented by subclassing the UI views for files and folder and enabling those special views on the file system folders representing your projects. A whole IDE integrated into the desktop by subclassing standard desktop objects. As an example, the standard file system explorer window would show IDE-specific columns in details view and a toolbar with build/run/debug buttons when you were browsing a folder which corresponded to an IDE project. Cool idea even though not perfectly executed.

Good memories.

Edit: fixed some typos and clarified last paragraph with an example.

Yes it is

There have been many requests to make it opensource, but apparently this was not possible because some part of the code are owned by both IBM and Microsoft who collaborated on OS/2 at the beginning before Microsoft decided to build its own Windows. Rumors are that while IBM was positive about open sourcing OS/2, Microsoft did not give consent.

I have been an OS/2 user back in the days, the system was great at that time, much better than the Windows counterpart, with a great UI and file system (which for example did not need defrag). It was however affected by one major issue: at the UI level it had a single event queue (http://www.os2ezine.com/v1n5/queue.html) and if some application would hang while processing its events, it would freeze the UI for good.

Apache Shenyu API gateway graduates from incubation to top level project

This article is biased:

"That innovation was the essential ingredient behind decentralized finance (DeFi) and NFTs"

as if defi was already globally in use! And later:

“Rightly or wrongly, she'd absorbed a very toxic environmental narrative,”

I am actually very glad that new generations have a much better understanding of environmental risks and I find very difficult to sympathize for a ecosystem that is such energy greedy.

I disagree, statistics demonstrated that the death number largely decreased among vaccinated. As such to me "forcing" vaccination is legit if it saves more people than it harms, it's for the greater good.

Personally I don't want to risk my life because my neighbour is not vaccinated, but on the other hand no one is preventing my neighbour from relocating to an isolated hut on the top of a mountain and avoid any contact with anyone if he/she does not want to get vaccinated. But as long as my neighbour wants to live in a city then he must comply with the decisions of the majority of people, who, at least in my country, rushed to get vaccinated as soon as possible.

It's the same with politics: sometimes politicians are elected which I don't like, so I can either accept the decision of majority of electors and live with that, or I can move to another place. What I can't do is decide that I refuse to comply with a law because it was enacted by a government that I don't like or didn't vote.

"Based on this I felt like some of the big winners in 2050 will be Rust, Clojure and Go. They mostly nail these criteria and are well-designed for not relying on containers or other similar technology for basic testing and feature implementation. They are also (reasonably) tolerant of spotty internet presuming the environment has been set up ahead of time."

Why is Clojure better then Java when it's a JVM language as well? It uses Java artefacts (Maven) so how is it more tolerant than Java of a spotty internet? Scala, Clojure, Java, Groovy should all rate pretty much the same or am I missing something?

I believe it largely depends on the business domain. I worked for many years in fintech, for banks and insurances.

Consider the following examples. Insurance: Given 10 input fields about a potential customer, produce a quotation and an illustration for a life insurance policy. At the UI level you create a form or a set of pages to collect birthdate, gender, job, hobbies, smoker/non smoker and so on. At the back-end level the above reflects in countless queries against trivial decision tables, and a lot of business logic and maths to be applied for each year/month of the policy duration in order to create a projection of the insurace coverage, taxation and many many more. The front-end will eventually display a nice table with all the numbers.

Fintech, financial planning. Collect your client needs (buy a house in 10 years, buy a car in 5, pay college for kids), propose an investment plan that starts with some initial investments in specific investment products with monthly installments, add some occasional big investments, project investments growth over the years using different mathematical and statistical formulas, produce a numeric data series that the front-end will eventually use to draw a plot chart.

In both above examples front-end work is way less complex than back-end. Technology could also imply complexity: at the back-end you may have to learn Java, Spring, Database, RESTful, some queue API (Kafka), big data for reports (Hadoop, Spark) and so on. All this complexity is hidden to the front-end developer.

On the other hand, if you are building a blogging platform, probably the complexity is the same at the back-end and the front-end or is higher at the front-end.

So in my opinion there is no correct answer if you don't take into account the business domain. Having worked in fintech, insurance, document management, few more in my career, in all these domains in my experience back-end was more difficult or at least not easier than front-end. Especially if you work in a product company, and every implementation needs to be carefully designed to provide stable API, design for changes, security, code optimised for large numbers of users (hardly a problem in front-end since JS is running on each user's browser).