nicfio

Today productivity is the mantra that drives the world of work. Too often products are released with the reason "as long as it works" and aspects such as security and performance are often neglected, and this costs effort and slipping of release times. The features of a product is only one of the aspects of software production: security and code optimization are other 2 branches of development that require parallel developments. Design of test suites, measurements, data analysis, study of optimizations and rewriting of code require effort and development times incompatible with the requests of managers and of the marketing department. Let's hope that the speed with which AI systems today are able to produce code will be used not only to produce new applications and services faster and faster, but also to optimize their code and make it more secure.

Good times of ISPF on IBM 3090/TSO. First you had to allocate a file on a dataset (ibm hates simplicity) and then you edited the text or copied with the pair "cc/mm" followed by a/b. No keyboard shortcuts, no interactive shell, only a data-entry panel and the incessant "tlac tlac" sound of the 3270 keyboard

Niche languages are fascinating, they recall a world that is disappearing, where it was necessary to think before writing, also because resources in terms of CPU and memory were scarce. I worked on IBM 3090 and the PL/1 language and I still remember the difficulty of getting print reports where you also had to calculate the number of columns needed to print a number. Now the arrival of data centers, and the birth of more modern languages like C# and Rust are replacing that world. Today speed is a fundamental element, and AI agents will end up replacing those who write code. But it is not the end, it is just the world changing. You are not a typist, but the one who thinks of new solutions.

I don't like Ubuntu. It was born with the intent of making Linux more user friendly, it changed policy wanting to become the Microsoft of the linux world: Snap, Mir. And then why use a derivative if I can stay on the original? I love debian: stable, it creates the right environment to feel at ease without the fear that every update can break something. Old software? flatpak and appimage solve the problem comfortably. The distro is slow? It's not true, maybe many don't know the magic of debootstrap. Many say that arch is fast, but the base rootfs weighs double that of debian and the speeds are comparable

Hi, I ran a test campaign on my machine to measure the differences between the various versions of firefox and chrome. The results are available on Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=2081675

I didn't use new versions of firefox because the system has to run on the current stable version of debian. On android it's simple: there chrome works perfectly, firefox I had to discard it because WebCodecs is missing completely, a whole class of features. Anyway I'm available to do a test campaign and give detailed information

I'm working on a demanding project that has performance as a fundamental requirement. Unfortunately Firefox turned out to be disappointing: audio/video codecs not supported or supported badly, and decidedly poor performance. Chrome instead is decidedly on another level. My opinion is that firefox prefers the road of features, neglecting the care of performance, and maybe this also depends on the fact that Mozilla doesn't have a big company behind it like chrome has google. It's a big problem, because on this road I don't see a great future for firefox, and we would end up on a road of de facto monopoly, which is not good for anyone.

Building an OS is a demanding job, and it becomes even more so if you decide to make the work public, because at that point you take on a commitment towards the people who follow you. If the project stays for private and personal use, well, an LLM helps us and then we update the work when we feel like it and have the time. LLMs are an extraordinary tool, but they don't answer the questions "what do you want to do with it?", "are you able to take on and keep a commitment?". As with all things in life, it's always a question of balance: how much do we want to spend for a tool that maybe could turn out to be not very useful? And what is useful? A 50 MB OS might not have many practical uses, but it would force us to study, and a lot. Could you put a price on learning new things?

LLMs produce code faster than humans are able to check it. Today's systems are able to generate thousands of lines of code per day, no human team would be able to keep up with them. The problem, in my opinion, is the way LLMs are used. An LLM reasons and makes mistakes according to the logic it was created with, but different LLMs reason and make mistakes in different ways. I'll give an example: take 2 black boxes, each one with 2 inputs and 1 output. Inside, the boxes work in a different way: with the same inputs the outputs are different. The real key is to use the method of adversarial development: this reduces to a minimum (even if it doesn't eliminate completely) the possibility of errors. So to humans the task of checking the output, and to have quality output you need to spend, and a lot, at least 2 frontier LLMs. But the question is: is quality as a goal an expense or an investment?

Implementing a network stack, maybe with reduced functions and written directly in C and/or Assembly, should keep the size of the OS low. It's a lot of work, and at some point you will need to make a careful evaluation between the effort and the result you want to reach. Also it wouldn't be bad if you allowed a certain margin of flexibility: 60 MB instead of 50 MB shouldn't be a big problem, and a lot of assembly code fits in 10 MB. For updates you need to plan a dedicated repository, because the software has to be dedicated, not use packages from the standard distros. Yes, a hyper-optimized 50 MB system is a lot of work, and in fact embedded systems generally have very outdated software versions.

Agreed, Tiny Core Linux is made exactly to run on old and low-powered PCs. But you can think of a more radical solution: take inspiration from Tiny Core and, using frontier LLMs, build your own tiny and personal Linux. With this solution expect a long work, but in the end you will have a system designed for you, that fits your needs perfectly.

The moment is delicate, but this has always happened. In the computer world changes follow one another at an impressive pace. I got passionate about computers in the early '80s with the Commodore VIC-20, and then on and on until the arrival of AI systems. Every time it was a new challenge: from typing in decimal codes for 6502 assembly to the C language, passing through BASIC and Pascal. Then object-oriented programming turned everything upside down: from functions and the procedural method to objects, and every time generations of programmers had to start again from zero. Today is no different. We are moving from writing code to designing architectures. We are not asked to learn how to write something, but to imagine how to build complex systems. We have to face the challenge of evolving from worker to engineer: not "doing" but "designing" and "imagining". No more arms and hands, but mind and imagination.