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

[pal666]

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.

annotations required to convert c++ code to rust ave voluminous enough to turn it into an uglier, less-pleasant-to-read-and-write and less powerful c++. c++ is evolving along with its static analyzers. and it does it faster than toy languages like rust

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.

i wonder when you'll chose rust over c++ to write rust's compiler

[ssokolow]

annotations required to convert c++ code to rust ave voluminous enough to turn it into an uglier, less-pleasant-to-read-and-write and less powerful c++. c++ is evolving along with its static analyzers. and it does it faster than toy languages like rust

Obviously. There are a lot more parties involved in C++ at this point in time, which means more manpower. That doesn't change the fact that C++'s evolution is limited by legacy concerns.

As for the "toy languages" comment, I don't think that needs a response. Feel free to take that up with Microsoft, Amazon, Dropbox, and all the other companies that are interested in Rust. Google just recently posted an overview of their explorations into making bindings between C++ and Rust quicker and easier to write so adding Rust components to Chrome is viable.

i wonder when you'll chose rust over c++ to write rust's compiler

First, I didn't write Rust's compiler. Second, the parts that are unique to Rust are written in Rust, and they're working on a Cranelift backend for faster debug builds, which will allow a pure Rust build option.

Reinventing LLVM at this point in time, just to avoid a dependency on C++ for release builds, would be foolish. It's work enough getting the LLVM components rustc shares with clang caught up with GCC, such as the optimizers.

I might as well mock you for using the Linux kernel when it hasn't been rewritten from C to C++ to be properly correct when undergirding your C++ applications.

[pal666]

Obviously. There are a lot more parties involved in C++ at this point in time, which means more manpower. That doesn't change the fact that C++'s evolution is limited by legacy concerns.

it's not c++ evolution what is limited by legacy concerns. it's switching to rust. which makes all your arguments moot

Reinventing LLVM at this point in time, just to avoid a dependency on C++ for release builds, would be foolish

funny that it somehow works only for rust itself, everyone else must reinvent their code in rust asap

I might as well mock you for using the Linux kernel when it hasn't been rewritten from C to C++ to be properly correct when undergirding your C++ applications.

you can't, coexistence with c code is one of selling points of c++

[ssokolow]

funny that it somehow works only for rust itself, everyone else must reinvent their code in rust asap

When did I ever say that? RIIR (Rewrite it in Rust) is something idiots say like a broken record, which reasonable Rust programmers are sick of doing damage control for.

Hell, we came up with the term "Rust Evangelism Strike Force" for those people... it's not a complement.

you can't, coexistence with c code is one of selling points of c++

It is for Rust too. Rust was specifically designed to be good at interoperating with C in the same way C++ does.

[mulenmar]

If it's failing that often, you should really just ditch NVIDIA.........or stick with an LTS kernel.

Oh believe me, nVidia would be kicked to the curb in a heartbeat if AMD's OpenCL acceleration in Blender worked as well as nVidia's offering.

And frankly, given that I'm still only on a GTX 950, the performance with GPU acceleration is barely better than running on the i5-45xx even with the appropriate rendering settings for each, that's not much of a blocker.

I need the money for other things though, and absolutely nothing else I do needs a newer GPU.

[SystemCrasher]

I'm not sure why you're continuously using .NET as a bad example of Microsoft's behavior.

Because I've seen how it performs in production and what it takes on .NET devs. And yea, I've seen some failed projects - and dare to think MS attitude helped them to reach failure state a lot. I've also seen many other projects, relying on different techs - so I had chance to compare things. I've got impression MS doesn't gives a crap what would happen to their downstreams. And even when they started to dump sources and so on, they still increadibly deaf when it comes to bug tracking and dealing with downstream woes. I've saw funny showcases of that - for both .NET and other MS products. Ironically github made this kind of thing even more visible. Funny, isn't it?

Oh, wait, weren't M$ so pushy to "improve github security" as to f...g up devs by causing loads of woes recently? Friend of mine complained that gh unlogged him and insisted on confirmation code just because they used "different browser". Isn't it funny when you waste your time not to chew on your projects or collaborating others but to struggle with M$ "security" telemetry/tracking crap?! One more showcase of how useful and friendly M$ could be for devs and their projects, dammit.

.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.

I dont like it - as well as M$. And I've got my reasons for this, obviously. Sure, M$ is good at sweet marketing B$. Much less good for actual production environments though. Starting from funny LSE showcase, where sweet .NET marketing turned into EPIC FAIL M$ continued their rather ... weird approach to production.

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.

I've seen plenty of glaring examples on github where MS grossly disregarded feedback or did some really weird actions that don't help much. Oh, sure, it's a hard thing to (try to) learn old cow to dance. That's a best metaphor I can imagine for what I've seen.

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.

That's quite misleading. Most devs are hired by MS, so good luck with forks. Oh, and taking all people around for idiots isn't very nice either. Funny example could be Xamarin and their products. And Russinivich products if we'll take a look into past. Ironically, later don't even have sane replacement it seems. So basically M$ marketing decices some cool stuff, M$ eagerly implements it, downstreams curse all things around and ... basically they're on their own. So I'd say it really bad to depend on MS and their techs.

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.

I'd say some things changed, but it still trying to learn old cow how to dance. There're much better dancers now. E.g. when it comes to web, I've never seen e.g. Google screwing Go users that badly EVER. Nor they try to push it everywhere. They have much better idea of production envuronments - and issues ppl face there. On other hand I still take M$ as very scary company/techs to depend on. And even if they dump sources it doesn't makes them really open minded or something. Just aggressively pushing marketing BS and shunning eveyone who dares to disagree is hardly open minded approach. Admitting "yes, but we couldn't/wouldn't fix it" hardly counts either. Realistically, I would have a problem to name less cooperative upstream so far.

The telemetry is a problem, though. However, that's not specific to Microsoft, every company does that now,

Ha-ha, well, somehow I have tools and OS without all that. So I'd say, I've got quite advantage. Why I'm supposed to use bastardized tools from foul company?

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.

I'd say it got something to do with opensource projects. I've always valued honest approach as one of things opensource brings with it. If MS can't afford that, well, they've got snake oil it seems. That's what their "opensource" worth of.

[rogerx]

I just went to enable scrollback buffer for viewing init messages on console prior to starting X/xorg, and guess what?

@#$@#$ Some click-n-play user wiped the code feature from the Linux kernel! Click-n-play user probably also uses some SystemD system, as SystemD renders scrollback buffer useless for debugging.

Can't wait for others to start complaining due to broke init systems.

[sfjuocekr]

Ah crap, I was hoping it was just disabled by default these days!

Now I have no more use for scroll lock during builds where I want to check what warning just scrolled past!

edit: or when the boot process fails for some reason!

[gotar]

As time has passed and nobody stepped in to revive scrollback on fbcon, I got an idea for you.

The main problem with software scrollback was rotten code with many interactions (VT vs DRM ioctls). However, usually we do not need the visual representation of the text scrolled off the screen. Moreover, such visual was only suitable for manual reading or taking a photo (no grep, no saving to a file).

The better would be to have the scrolled back contents available via some file (think something like /dev/vcsa* now); kernel holds only some per-console ring-buffers with actual letters and theirs attributes (not rendered glyphs), userspace tools can represent them.