Inkscape is another pretty good one, or some KDE applications.

I have less hate for the java language than it's implementation. I've never used the language, so I care nothing about it. The runtime is a nightmare to deal with and maintain.

Then there is your typical java proponent. So many I have talked to are ignorant of important things like how hardware works and basic computer science principals. These are the same people that start conversations like "why do people still use C?" And, "why isn't there a Java based OS?"

I don't touch anything else than Linux and FreeBSD. Win, brrr,...
I use BASH, C and C++, mainly, for Unix principle reasons.

It does not matter very much the programming language.

This is why I said that thing minimum dependencies. Since many libraries used in BSD and Linux are completely bloated, you'd better do it from scratch with X11 and Intrinsic.

Look GTK, do you believe that it is OK? - Not for me. Most of the Linux desktop is bloated.

Even better, good ugly softwares are disappearing. A good example is Ubuntu. Ubuntu is slow and removing intentionally small, efficient, applications from the repositories.

Nope, I'd prefer to stay away from the Gnome ecosystem, but that's not currently possible as Glib is a minimum requirement for almost all desktop components.

I don't like vala or, more precisely the side-effects that come from having it around. I'm still trying to figure out how gobject-introspection came about. Was it the want of object oriented programming in C? Then they should have used C++ or Objective-C. No, I suspect it was the only way to be able to actually use an unstable API where the developers change things on a whim. At any rate, the whole thing seems backwards to me.

I was actually considering looking into Vala for a future project, because the ElementaryOS team has had great success with it.

It looks to me another Ubuntu.

I am a bit surprised that you like using such highly desktop user-friendly, shining/flipping/..., desktops with superbe GUIs.

I mostly do C, but I grew up on assembler. I've done some C++. Very little java, at one point in time I made my personal website a bunch of java applets (more like j++ applets). But I came to my senses as it didn't run on 50%+ of the browsers / desktops relative to other peoples computers. And a text document shouldn't take 70% of your CPU cycles, no matter how "pretty" it is. If I learn another it'll probably be python, although I kind of already don't like it. Speedometer is python and hogs 70% CPU on the Raspberry pi B for only monitoring traffic ONE WAY. But a lot of software defined radio is python, so I better get intimmate with it someday. I was tempted to do RPerl the other year, but it didn't seem to install cleanly even on recommended distros. And I couldn't get the demo things to compile to get a better handle on low magic versus high magic. Rust or Haskell get mentioned a lot, but I'm a C type since most of the things that interest me are near the kernel level of doing things. All that being said and done, about the only thing I've "written" in the past decade is a bunch of bash scripts.

Give golang a try. It's a small language like C and compiled. It does use a GC at runtime, but it's optimized not to shut everything down. If you don't want to use the GC you can use memory buffer requests to preempt it.

If you look for instance a basic installation of Linux, there are many many programs that aren't needed at boot time. Perl and python are needed otherwise the Linux machine will not work.

Luckily that the kernel is made in C language, otherwise the whole Linux would be like the distribution installation.

Distributions are needing 400-600 Mb for the base system when Linux could run on 100-150 Mb, including the kernel when it is well compiled to essential.

Programmers do not worry much about performances, but no one does really anything. There is no alternative distributions going to essential and focused on having a working Linux base system. Without Perl, Python,..., twenty thousand daemons, systemD, Avahi,... and bunch of non necessary.

With a Raspberry Pi, people will realize that there must be a rewrite to C of many Linux components and softwares, which aren't optimized.

Recently I made a rewrite of ls, cp,... and the basic binaries perform fairly slow compared to binaries made in C and from scratch.
One can test ls made in C from scratch versus default ls in a distant SSH connection. ls is slow in comparison.

I simply don't understand it. Can you please explain it in more details. How ssh is related to it? Which ls is slower than the other?

ls & cp are already written in C on my system.

If you think building a couple is fast. Try building a whole system from scratch and only installing what you want. Here's my pstree...

The ssh is because I'm building from another system. Avahi is there as an experiment and I'm seeing what it will do for network printers. Notice what's not there? Krb5, LDAP or Sasl. Why? Don't need them, I can use rsync, sshfs or scp to transfer files at home. Why increase my attack surface for network services I don't need, I'm not at work.

Anyway, here are my times...

<Enter>@Grub to Console Login: 2.9 seconds.
<Enter>@Grub to SDDM Login: 3.2 seconds.
Startx to OpenBox Session: 1 second.
Launch Gvim, xterm or idle: 0.5 seconds

I can't give you a web browser, vlc or file manager yet because the desktop isn't done yet.

I like the fast build times that golang supposedly touts. But something about it not doing shared libs, that turns me away. It's supposed to make big projects more manageable, but no shared libs means your big project is EVEN BIGGER. Pass.

Everyone touts how much faster their systems are with SSDs and NVME. But most of what I use isn't big enough to be affected by disk I/O. With the exception of a web browser. But my ISPs is a wireless one and my bandwidth low enough to make all browsers appear to be the same speed. Until I use one of my older and lower spec'd machines then just bringing the browser up is like playing craps in a back alley. Or roulette, ... winner ... on 10 minutes and 56 seconds... At which point disk I/O does matter because ... swap.

It uses shared libs on your system like anything else. It's the go library that gets compiled statically, or any that you download, write or use written on golang. If you use something from libc, or FF's from non-go libs, the linker is still called.

I think the idea was: what's the point? Most of the time when you use a python or other non-C/C++ language you end up downloading and installing dependencies anyway. So why not just have your applications take those libs specific to it's use with it. It wasn't designed for building or replacing system libraries, it was designed for applications.

On a distant connection, slow, via SSH. I don't know but /usr/bin/ls performs much slower than mine, 5sec / few sec differences.


Man!!! This thing below is terribly scary, really. I can't believe what I see.