Linux 5.9 Dropping Soft Scrollback Support From FB + VGA Console Code

[grok]

Unless something went VERY wrong, just having a secondary desktop available would have been enough. Like IceWM or something, not a full DE, just a GUI.

debian/ubuntu has the lxde-core package which might be an absurdly small DE, you get the gtk2-based panel and file manager (which manages desktop icons unless it crashes) but not even a terminal emulator or text editor. That's not in the scope of the DE.

I never knew why I don't like icewm very much but I can mention jwm which gives a gray win95 taskbar (w/ multiple virtual desktops I believe). Doesn't set the background, pure window manager. I never last very long.

mwm, Motif window manager is charming. It's Windows 3.1 without the Program Manager. That makes it extremely easy to use! It was made before the fall of the Berlin wall but stayed proprietary for decades. Gnome 3 should take hints from it. Can't understand any kind of panels or docks. For unrelated reasons I'd be interested in finding a simple applications launcher that works as a regular window. Not a dock, no overlay window, no hotkey-activated box, no modal menu. Just like every normal running program. Would allow to launch games and nice things (you create/add shortcuts in there). file/edit/view bar.

[grok]

My GNOME was broken some days ago, so I couldn't run X nor Wayland and was forced to repair the system using the console.

I would like a 4K console with Unicode, 256 color support, 24-bit true color support. Maybe some really nice looking 4K-suitable font too. Mouse support would be nice too.

I had the console running at 2048x1536 against my will, on CRT monitor.
apt-get install gpm gives you a mouse cursor immediately, don't need to login again which is a nice little thing. As you won't right-click on anything, the right click does paste - you won't need a third mouse button.

[ssokolow]

Michael ping for unapproved comment.

EDIT: ...and there it goes back to unapproved because I noticed a mistake I had to correct.

[ssokolow]

(long post about static vs. dynamic linking)

You'll want to read these two posts:

• Dynamic Libraries - Drew Devault (Research, with graphs and commands you can re-run yourself, on how dynamic and static linking actually compare.)
• Let's Be Real About Dependencies (Specifically, the "Gotta go deeper" part about how often, for want of proper package management, C and C++ projects use things like header-only libraries and "nobody else uses exactly this code" home-grown reimplementations of things that would be external crates in Rust, neither of which can be meaningfully split out into shared libraries by distro maintainers.)

(stuff about Mozilla and Rust)

What you said feels very "I think X. Prove they didn't" paranoid rant-y, but I'll reply to what won't take two days of research to counter.

I can imagine how it could turn out - "Microsoft, the best opensource f(r)iend". These already expressed idea of using Rust more, sounds like a hint what would happen next.

Both Microsoft and the Google Chrome team found that, despite all the effort and money they've poured into making C and C++ safer, they're still hovering at "70% of all CVEs are memory bugs Rust can prevent". The Benchmarks Game shows Rust as the only major language that's performance-competitive with C and C++. (There's enough noise in those results that C, C++, and Rust trade their ordering from month to month.)

Microsoft is just one of multiple big-name companies that would be foolish not to be interested in Rust. (Microsoft, Google, Amazon, Facebook, Dropbox, Cloudflare, Discord, etc.) If "Microsoft is interested in it" is your metric for avoiding something with technical advantages, then you're going to be bouncing from niche product to niche product like a hipster.

At the end of day it ended in ultimate vendor lock of addons ecosystem

I was on Bugzilla when they made that decision. It was in response to crapware installers that were doing things like looking up Firefox's install location and editing prefs.js to loosen extension auto-installation restrictions, or displaying a borderless shaped window over the browser to make it look like Firefox itself was guiding users through OKing the crapware addons.

In the face of that, they decided that requiring a special build of the browser with a different icon and branding (Developer Edition, Unbranded Builds, etc.) was the only reliable way to ensure that the ability to blacklist bad actors from grandma on the standard, stable build.

I don't like it, and I write Greasemonkey/Violentmonkey/Tampermonkey scripts instead of browser extensions because of it, but I understand where they're coming from and at least it's not the "pay us a one-time $5 fee for a Chrome extension developer account so your credit card can be blacklisted if you write malware" Google policy.

Well, for me it's kinda enough to stay away. MS proven me multiple times I would regret MS-backed beauty. Starting from WinNT. Well, it has been beautiful around Win2k - a reasonable API, plenty of features, light, stable, kernel designed by pros... but it proven to be a very regrettable decision over time. Because M$ marketing managed to turn it into nightmare, using all that for vendorlocks and racket-like activity.

Windows is closed-source. TypeScript and Rust are open-source under licenses that allow things like "Stallman is being an idiot about GCC. Let's fork it into EGCS and prove our view so right that he relents and makes it the new version of GCC." or "Oracle is being dicks about OpenOffice.org. Let's all leave and make LibreOffice." Big difference.

If I have to 'trust code', C/C++ at least got truckload of static analisys tools (opensource included) that make this trust a bit more backed by somethnig more substantial.

That's like saying "I'm not going to buy your FooCorp car (which comes standard with seatbelts and airbags) because an aftermarker ecosystem of seatbelts only exists for my BarCorp car." Rust's compile-time guarantees are stronger than what static analyzers offer for C and C++ and that can't be fixed because the annotations required to add the requisite information to C and C++ code are voluminous enough to turn it into an uglier, less-pleasant-to-read-and-write Rust.

Not to mention truckload of preexisting battle-hardened code and compatibility with nearly any kind of language.

It's called a C foreign function interface and binding generators and Rust was specifically designed to be very good at both.

Hell, If I want to write a compiled extension to something with a higher-level interface than C, like Python, Ruby, Node.js, etc. [1] [2], I'd choose Rust over C or C++ any day.

Yet to me it looks half-proprietary thing only targeting interests of few megacorporations despite formal declarations. So for me it somehow looks much like a cheese in mouse trap. Sure, it could be tasty...

That which can be asserted without evidence can also be dismissed without evidence. -- Christopher Hitchens (on arguments in favor of God's existence and the "you can't disprove God" argument)

[Ironmask]

Well, maybe because I've seen how e.g. .NET apps development looks like and don't want something like that landed on my head by someone like M$? . And I really doubt MS loves linux. They only love 2 things: marketing bullsht and money. I guess all these playings with linux are the former. It just bad for reputation to be opensource-unfriendly these days. Yet, same proprietary vendor-locked spyware-like crap at the core. That even gone as far as supplying builtin keylogger "to improve user experience". I'd say it's better to be careful with f(r)iends like this.

I'm not sure why you're continuously using .NET as a bad example of Microsoft's behavior. .NET is a beloved and widely-adopted platform that's improving every year. You may not like it, but many other people do. That doesn't make it bad.

And exactly, it's bad marketing to be open source-unfriendly now. That's a good thing, Microsoft is actually listening to market demands outside of their own products for once and allowing fields to adopt their technologies that wouldn't have done it before. And no, that's not some evil tactic to worm their way into places, their products are open source, anyone can just fork them if they decide to break them. MS going rogue wouldn't be any different from a developer getting hit by a bus. But they won't do that, because, as you said, that would be marketing suicide. And don't try to say MS would just start suing people, because they didn't do that even back when Ballmer was around and Mono was being worked on.

The telemetry is a problem, though. However, that's not specific to Microsoft, every company does that now, that's just the nature of information being the new oil. Not much you can do about that. It definitely doesn't have anything to do with how Microsoft thinks about open source projects.

[SystemCrasher]

Even the Year of Our Lord 2020 where MS is literally saying they love and celebrate Linux and open source and have opened sourced their own languages, there are still Linux cultists who are stuck in 1990 and still think Bill Gates is CEO. So they bash the company senselessly, unprompted, like a hate-crush.

Well, maybe because I've seen how e.g. .NET apps development looks like and don't want something like that landed on my head by someone like M$? . And I really doubt MS loves linux. They only love 2 things: marketing bullsht and money. I guess all these playings with linux are the former. It just bad for reputation to be opensource-unfriendly these days. Yet, same proprietary vendor-locked spyware-like crap at the core. That even gone as far as supplying builtin keylogger "to improve user experience". I'd say it's better to be careful with f(r)iends like this.

[SystemCrasher]

[*]Mozilla Corporation and The Mozilla Foundation are not the same thing.

That's formally true, but I guess it more or less same persons plagued by more or less same problems. Granted they fired e.g. servo devs and so on - I'd say things don't run well for them and there're reasons.

[*]Did you read an article I missed that The Mozilla Foundation has plans to sell Mozilla Corporation (the corporation is a wholly owned subsidiary of the not-for-profit organization) or are you just speculating based on the lay-offs?

Personally I think Mozilla...
1) Failed their mission. Beast got poisoned and spoiled by some scary and awkward management. I've had enough with their addons signing saga, a lesson I wouldn't forget.
2) They give no crap how their actions turn on their users/downstreams. Google could even sometimes afford it... too bad they aren't Google.
3) Granted such a colorful history I would expect nothing less than that about rust crates. Would be good if I'll be proven wrong on it.
4) They lost their momentum, dissipating efforts and ending up with bunch of crap and management to match. I don't think it fixable.

[*]It was mentioned right here on Phoronix that they're preparing to spin Rust off into a foundation of its own.

I'd say it's great idea. But they are late. Granted what they are now I really doubt they stand chance to implement it reasonably. I can imagine how it could turn out - "Microsoft, the best opensource f(r)iend". These already expressed idea of using Rust more, sounds like a hint what would happen next.

[*]What would Microsoft control? It's all open-source, we're seeing more and more interest from other rich, giant corporations like Amazon who wouldn't take too kindly to Microsoft trying to dictate terms to their cloud hosting competitors, and everyone's used to an open governance model rather than a BDFL model like in something like Python.

Well, I can imagine they would join foundation and e.g. repeat OOXML story, heavily lobbying what they are up to. They are good at this kind of crap. And I've saw how overall Mozilla governance performed, thank you very much. At the end of day it ended in ultimate vendor lock of addons ecosystem - so I wouldn't hold by breath unless things prove otherwise "in field". Plans aren't actual actions.

[*]C is as clean as it is because nobody important cares. Microsoft has been pumping all their "we use this internally, so let's standardize it" clutter into C++ via their membership on that standards body.

I'd say, they fortunately got obsessed on .NET so they f...d up only a very particular bunch of unfortunate souls. I've had pleasure of seeing their faces when new .NET is out - so everyone of coding team urgently recalled from vacations or something because "our program has totally stopped working" kind of jeez. And looking on all that I'm not really sure how valuable such contributions are for !(Mircosoft).

[*]TypeScript is pretty nice... does it change your perspective on it to know that it's a Microsoft project?

Well, for me it's kinda enough to stay away. MS proven me multiple times I would regret MS-backed beauty. Starting from WinNT. Well, it has been beautiful around Win2k - a reasonable API, plenty of features, light, stable, kernel designed by pros... but it proven to be a very regrettable decision over time. Because M$ marketing managed to turn it into nightmare, using all that for vendorlocks and racket-like activity. At which point you learn beautiful tech solely owned by things like MS turns to be just pain in the rear. At which point I had to reconsider ideas about beauty a bit.

[*]Rust doesn't technically have only one implementation. mrustc may not have a borrow checker yet, but, as long as you can trust that the code is good, it'll compile it.

If I have to 'trust code', C/C++ at least got truckload of static analisys tools (opensource included) that make this trust a bit more backed by somethnig more substantial. Not to mention truckload of preexisting battle-hardened code and compatibility with nearly any kind of language.

I'd say Rust got some funny ideas... and even got some things right. Like e.g. using macros to avoid code generation. Yet to me it looks half-proprietary thing only targeting interests of few megacorporations despite formal declarations. So for me it somehow looks much like a cheese in mouse trap. Sure, it could be tasty...

[SystemCrasher]

This use to trump any argument in favour of static linking, but it went out of the window with the introduction of snaps, flatpak, appimage, etc

That's exactly why I moved to Debian from Ubuntu - just don't want unsupportable, unmanageable windows-style trash in my systems. I aleady had enough of that in Windows - and I'd say package management improved state of things for me hell a lot. Yes, it comes at price - like not the most-recent most-shiny fresh bugs out of bakery, etc. On other hand it means rock-solid prodiction environment, where I can chew on my projects without fallouts, management woes and silly security breaches.

But of course it is possible to turn Linux into Windows-style trashbin, plagued by pretty much the same problems - actually you can do it to any system that can run programs. So at the end of day it bolis down to question "who cares of library updates, why and when?!". Seems in your case answer is generally "nobody - let's bad guys pwn the world". That's an option - but speaking for myself I don't like it.

Not necessarily and in fact rarely. Unused portions of the file do not need to be in RAM.

There is no a priory knowledge what would be used and what would not. Actually, when you can have such knowledge and dead sure it is a case, any decent compuler would optimize it out, to begin with, so it doesn't even makes into final binary. Especially with something like LTO.

Have you investigated the overhead of the dynamic loader ?

A valid point - but if lib is already loaded, it wouldn't be loaded and re-parsed once more, if I remember. So it mostly concern for unique and big libs... and if something is big and unique it raises a question "WTF it's named a lib?!". Well, like a half of idea behind libs is to promote sharing of code. But of course it's possible to reinvent wheels everywhere. Yet, in my opinion it doesn't works terribly well. At least I had enough of this kind of crap in Windows and has been more than happy to part my ways with this approach. Saved me truckload of time and efforts, should I say.

The code sharing happens at compile time and not run time when doing static linking.

And so it doesn't happens beyond program boundaries - compiling everything into super-binary would be a bit extreme (alright, some special cases like busybox go for it, for exactly that reason). Not a big problem for sinle-service container or so, but quite resource-inefficient for e.g. usual desktop.

If the static library was create in the correct way (which very few are, sadly), you only link in the code that you actually use.

And even better with LTO... that can even obliterate or optimize some parts as if that just one big chunk of code it can chew all at once. But it limited to program boundary and therefore is resource-inefficient in multi-tasked environment if there're programs using same lib. So lib code would be held in memory N times if there're N statically linked programs. If it dymamic linking there is just one core set of lib pages and then N small differences. That's likely in part what makes fork() so damn efficient thing on *nixes.

Contrary to how dynamic libraries work, where everything gets put in a huge blob.

1) It only partially valid statement. Say, Qt, KDE, ... got more sane splitting as they grown in size. So it more of project management level issue - when lib dev disregards code size growth.
2) What you said about not keeping unused parts in RAM also applies here as well.
3) RAM representation of blob heavily shared across its users, saving RAM. Nor there is full loading of that code/data when new program using same lid starts. Yet, a funny abstraction (CoW, Linux calls it RCU in this case) keeps illusion that pretends like if all apps have unique address space. If they try to actually touch that, and change that - affected page(s) would get unshared, sure.

I think rust have an initiative to create static libraries the correct way. They boast about only pay for what you use.

Guess I don't share this view...

With the exception of libc, the shared usage of the dynamic libraries are much less than people are led to believe.

Nope! In my system all Qt apps are using same Qt instance. So while starting 1st Qt app may take some time, other instances or even other Qt-based apps would be much faster to launch. And I take it as rather big efficiency and lib management feature. And granted all that I wouldn't count on "security" of rust progams since it seems things are hevily f...d up on far more fundamental levels and while solving some problems it brings whole shebang of new ones.

[Raka555]

If you link everything in static way...
1) You can't just replace one lib and fix whole system if some bug/vuln/whatever found. Locating and rebuilding all users of lib suddenly turns into managenent nightmare. Some scenarios can get with it, but in some (think of usual desktop) just happens to be dead end.

This use to trump any argument in favour of static linking, but it went out of the window with the introduction of snaps, flatpak, appimage, etc

2) If your binary is larger, runtime memory usage is larger. Well, at least that code/data generally have to be in RAM, right?! (really it more complicated, but idea stays)

Not necessarily and in fact rarely. Unused portions of the file do not need to be in RAM.
Have you investigated the overhead of the dynamic loader ?

3) If you link lib statically... there is no way to see other programs use same lib and only keep single instance of that in memory anymore. Can you imagine, these days all sane OSes around would keep only one instance of dynamic lib code/data as long as they are identical - and so mem usage only grows when copies actually diverge, usually slightly. Static linking obviously breaks this process.
Say, run 10 apps using dynamic Qt - and only 1 instance of Qt would be in memory (+/- small differences of each instance). Run 10 statically linked apps - and you have 10 independent instances of Qt in RAM, not anyhow sharing pages anymore. Just because nobody even knows this code is same or similar. So static linking causes resource hogging.

The code sharing happens at compile time and not run time when doing static linking.
If the static library was create in the correct way (which very few are, sadly), you only link in the code that you actually use. Contrary to how dynamic libraries work, where everything gets put in a huge blob.
I think rust have an initiative to create static libraries the correct way. They boast about only pay for what you use.

With the exception of libc, the shared usage of the dynamic libraries are much less than people are led to believe.

[ssokolow]

...wouldn't rule out M$ purchacing all that (as it depends on just mozilla corp, which apparently going to be for sale soon) - and then M$ would be able to dictate what is good and bad, ask for double-factor authentication or offload other "improvements" on your head - as everyone has recently seen on Github's example.

Oh, sure, some ppl don't get idea from just one punch - now primary fun is going to be around ARM, but I can imagine faces of Rust fans who would soon find self in same boat, figuring out solution locked on just one corp that got sold isn't exactly cool. C got quite an ultimate advantage in this regard: not controlled by single nasty corp! Sure, Rust got interesting ideas, but implementation, especially centralized repo locked on just one vendor is awful.

There is so much wrong with this post that I'm having trouble figuring out where to start.

1. Mozilla Corporation and The Mozilla Foundation are not the same thing.
2. Did you read an article I missed that The Mozilla Foundation has plans to sell Mozilla Corporation (the corporation is a wholly owned subsidiary of the not-for-profit organization) or are you just speculating based on the lay-offs?
3. It was mentioned right here on Phoronix that they're preparing to spin Rust off into a foundation of its own.
4. What would Microsoft control? It's all open-source, we're seeing more and more interest from other rich, giant corporations like Amazon who wouldn't take too kindly to Microsoft trying to dictate terms to their cloud hosting competitors, and everyone's used to an open governance model rather than a BDFL model like in something like Python.
5. C is as clean as it is because nobody important cares. Microsoft has been pumping all their "we use this internally, so let's standardize it" clutter into C++ via their membership on that standards body.
6. TypeScript is pretty nice... does it change your perspective on it to know that it's a Microsoft project?
7. Rust doesn't technically have only one implementation. mrustc may not have a borrow checker yet, but, as long as you can trust that the code is good, it'll compile it.