4 ms·

The whole linux stack got bigger though - just look at what you need now to compile stuff, cmake, meson/ninja, mesa, llvm and so forth. gtk2 was great; GTK is n

The whole linux stack got bigger though - just look at what you need now to compile stuff, cmake, meson/ninja, mesa, llvm and so forth. gtk2 was great; GTK is now a GNOMEy-toolkit only, controlled by one main corporation. Systemd increased the bloat factor too - and also gathers age data of users now (https://github.com/systemd/systemd/pull/40954 https://github.com/systemd/systemd/pull/40954). I guess one of the few smaller things would be wayland, but this has so few features that you have to wonder why it is even used.

ScislaC 6mo ago
Is the option of legal compliance a bad thing? They have corporate customers. If there's no opt-out, that's a different story.
- GrayShade 6mo ago
  It's plain FUD. systemd always had fields for the full name, email address and location. They were optional, just like the date of birth. Bad systemd!
  - anthk 6mo ago
    Is not FUD; the full name, email and the rest were not META/corporations mandated, which are lobbying for it so they can earn money with users' preferences. Get your spyware to somewhere else. If META's business model is not lucrative, is not my problem.
    - gruez 6mo ago
      >which are lobbying for it so they can earn money with users' preferences Given it's a field where you can put absolutely anything in (and probably randomize, if you want), how is this different than the situation today, where random sites ask you for your birthday (also unverified)? Moreover Meta already has your birthday. It's already mandated for account creation, so claims of "so they can earn money with users' preferences" don't make any sense.
      - anthk 6mo ago
        [flagged]
        gruez 6mo ago
        >Keep gaslighting: This is against HN guidelines: " Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith." >The contents of the field will be protected from modification except by users with root privileges. So... most users?
goalieca 6mo ago
I’ve been using cmake since early 2000s when i was hacking on the vtk/itk toolkit. Compiling a c++ program hasn’t gotten any better/worse. FWIW, I always used the curses interface for it.
curt15 6mo ago
>The whole linux stack got bigger though - just look at what you need now to compile stuff, cmake, meson/ninja, mesa, llvm and so forth Those are all development tools. Has the runtime overhead grown proportionally, and what accounts for the extra weight?
- array_key_first 6mo ago
  Runtime-wise we use more garbage collected languages now. Java and such are great and can be very high performance, the real cost though is memory. GC languages need much more memory for book keeping, but they also need much more memory to be performant. Realistically, a Java app needs 10x the amount of memory as a similar C++ application to get good performance. That's because GC languages only perform well when most of their heap is unused. As a side-note, that's how GC languages can perform so well in benchmarks. If you run benchmarks that generate huge amounts of garbage or consistently run the heap at 90%+ usage, that's when you'll see that orders of magnitude slowdown. Oh also containers, lots more containerized applications on modern Linux desktops.
  - jasomill 6mo ago
    Programs that manually allocate and deallocate memory to store "huge amounts of garbage" can easily incur more memory management overhead than programs using garbage collection to do the same. If a Java application requires an order of magnitude more memory than a similar C++ application, it's probably only superficially similar, and not only "because GC".
    - array_key_first 6mo ago
      Well no because in a manual memory management language if you allocate 1 object, and then destroy it, and then reallocate another object then you've used 1 object amount of memory. In Java, that's two objects, and one will be collected later. What this means is that a C++ application running at 90% memory usage is going to use about the same amount of work per allocation/destruction as it would at 10% usage. The same IS NOT true for GC languages. At 90% usage, each allocation and deallocation will be much more work, and will trigger collections and compactions. It is absolutely true that GC languages can perform allocations cheaper than manual languages. But, this is only true at low amounts of heap usage. The closer you get to 100% heap usage, the less true this becomes. At 90% heap usage, you're gonna be looking at an order of magnitude of slowdown. And that's when you get those crazy statistics like 50% of program runtime being in GC collections. So, GC languages really run best with more memory. Which is why both C# and Java pre-allocate much more memory than they need. And, keep in mind I'm only referring to the allocation itself, not the allocation strategy. GC languages also have very poor allocation strategies, particularly Java where everything is boxed and separate.

ScislaC 6mo ago

Is the option of legal compliance a bad thing? They have corporate customers. If there's no opt-out, that's a different story.

GrayShade 6mo ago
It's plain FUD. systemd always had fields for the full name, email address and location. They were optional, just like the date of birth. Bad systemd!
- anthk 6mo ago
  Is not FUD; the full name, email and the rest were not META/corporations mandated, which are lobbying for it so they can earn money with users' preferences. Get your spyware to somewhere else. If META's business model is not lucrative, is not my problem.
  - gruez 6mo ago
    >which are lobbying for it so they can earn money with users' preferences Given it's a field where you can put absolutely anything in (and probably randomize, if you want), how is this different than the situation today, where random sites ask you for your birthday (also unverified)? Moreover Meta already has your birthday. It's already mandated for account creation, so claims of "so they can earn money with users' preferences" don't make any sense.
    - anthk 6mo ago
      [flagged]
      - gruez 6mo ago
        >Keep gaslighting: This is against HN guidelines: " Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith." >The contents of the field will be protected from modification except by users with root privileges. So... most users?

goalieca 6mo ago

I’ve been using cmake since early 2000s when i was hacking on the vtk/itk toolkit. Compiling a c++ program hasn’t gotten any better/worse. FWIW, I always used the curses interface for it.

curt15 6mo ago

>The whole linux stack got bigger though - just look at what you need now to compile stuff, cmake, meson/ninja, mesa, llvm and so forth Those are all development tools. Has the runtime overhead grown proportionally, and what accounts for the extra weight?

array_key_first 6mo ago
Runtime-wise we use more garbage collected languages now. Java and such are great and can be very high performance, the real cost though is memory. GC languages need much more memory for book keeping, but they also need much more memory to be performant. Realistically, a Java app needs 10x the amount of memory as a similar C++ application to get good performance. That's because GC languages only perform well when most of their heap is unused. As a side-note, that's how GC languages can perform so well in benchmarks. If you run benchmarks that generate huge amounts of garbage or consistently run the heap at 90%+ usage, that's when you'll see that orders of magnitude slowdown. Oh also containers, lots more containerized applications on modern Linux desktops.
- jasomill 6mo ago
  Programs that manually allocate and deallocate memory to store "huge amounts of garbage" can easily incur more memory management overhead than programs using garbage collection to do the same. If a Java application requires an order of magnitude more memory than a similar C++ application, it's probably only superficially similar, and not only "because GC".
  - array_key_first 6mo ago
    Well no because in a manual memory management language if you allocate 1 object, and then destroy it, and then reallocate another object then you've used 1 object amount of memory. In Java, that's two objects, and one will be collected later. What this means is that a C++ application running at 90% memory usage is going to use about the same amount of work per allocation/destruction as it would at 10% usage. The same IS NOT true for GC languages. At 90% usage, each allocation and deallocation will be much more work, and will trigger collections and compactions. It is absolutely true that GC languages can perform allocations cheaper than manual languages. But, this is only true at low amounts of heap usage. The closer you get to 100% heap usage, the less true this becomes. At 90% heap usage, you're gonna be looking at an order of magnitude of slowdown. And that's when you get those crazy statistics like 50% of program runtime being in GC collections. So, GC languages really run best with more memory. Which is why both C# and Java pre-allocate much more memory than they need. And, keep in mind I'm only referring to the allocation itself, not the allocation strategy. GC languages also have very poor allocation strategies, particularly Java where everything is boxed and separate.