Devuan, anyone?

[Penguin-Guru]

Ok, thanks for your efforts. It will probably be ages before I get a Pyra in my hands (haven't actually ordered yet) but if nobody has tested by then, I will compare battery life and video performance on PyraOS to Devuan and/or SysD clean Debian.

Sort of a tangent but it would be nice to have a comprehensive list of differences between PyraOS and standard Debian. I imagine this would be generally useful long-term for porting, auditing, and version control but I'm not a capable programmer myself so maybe it's already available somewhere and I just don't know where to look.

Regarding Pyra hardware, the C.P.U. is supposed to be OMAP5432, which is nice and easy to remember. SGX seems to be a name associated with PowerVR's Series5 and Series5XT products. The relevant link on the Pyra Wiki's G.P.U. page (Link-1 below) seems to be dead and PowerVR's website's search bar is useless. Some technical information is available in a Wikipedia list (Link-2). I don't know if the manufacturer's link can be fixed but I think the info should be copy/pasted to improve the Pyra Wiki. I don't want to submit changes myself because I'm new here and ignorant about the technology. Just documenting my adventures.

Link-1: https://www.pyra-handheld.com/wiki/index.php?title=GPU

Link-2: https://en.wikipedia.org/wiki/List_of_PowerVR_products#Series5_.28SGX.29

 

[Linux-SWAT]

You may be interested in :
http://dev.pyra-handheld.com/

 

[Penguin-Guru]

Yeah, that's it. Thanks!

Now if only I had a Pyra...

 

[Linux-SWAT]

Well you can get an EVM or IGEP boards for around 300€ , but it won't fit well in a pocket ^^ .

 

[TrashyMG]

Well you can get an EVM or IGEP boards for around 300€ , but it won't fit well in a pocket ^^ .

challenge accepted.

 

[Magic Sam]

Hi all

Some "interesting" bits about Systemd here and here.

Cheers, Magic Sam

 

[Linux-SWAT]

Yup, this terrible bug are here since a year.

 

[tigerroast]

This should at least quiet the "conversation" about this minor bug.

 

[Letalis Sonus]

So... anyone else ended up with a horribly scrambled framebuffer while performing a minor systemd update recently? Never happened before and it was an incredibly well timed coincidence...

This should at least quiet the "conversation" about this minor bug.

One can't deny that there's some seriously valid critique about its architecture, though, no matter how you think about that specific bug.

 

[tigerroast]

So... anyone else ended up with a horribly scrambled framebuffer while performing a minor systemd update recently? Never happened before and it was an incredibly well timed coincidence...

Were you trying to manually update the systemd components themselves? If not, then idk what you mean about "systemd update." Also, never had systemd affect anything in the framebuffer before, and I use Arch (rather, did when my laptop could still turn on). I really don't know what you mean.

To be fair, on Arch, systemd is part of the Core package group, so updating systemd is handled through normal system updates (at least that's how I had it set up since I want the new shiny on Arch). Then again, I'd think that's how any rolling-release distro would handle the upgrading of core packages, no? If you're on a fixed-release distro, then playing with core packages might introduce some unexpected behavior.

I don't know your situation very well.

One can't deny that there's some seriously valid critique about its architecture, though,...

There are plenty of valid critiques surrounding systemd (the way it handles parsing, for example), but that has no bearing on why this bug is so minor.

...no matter how you think about that specific bug.

Doesn't matter what I think when the reality is right there.

 

[Letalis Sonus]

Were you trying to manually update the systemd components themselves?

I'm talking about an absolutely normal pacman update of libsystemd, systemd and systemd-sysvcompat (231-1 -> 231-3). They were the only packages being updated and running off an SSD the time window of it happening right during the update process was extremely small.

There are plenty of valid critiques surrounding systemd (the way it handles parsing, for example), but that has no bearing on why this bug is so minor.

I was actually referring to that infamous blog post which was heavily criticized for being loaded with anti-systemd propaganda afterwards.

 

[comradekingu]

Were you [scenario] or trying to [thing]?, is not so much explaining away the issue, if it happens to be "running vanilla Debian", without being vulnerable to what would otherwise be an init-script.

That isn't a 'minor bug', nor is anyone pointing it out otherwise anything. It is a real issue, for a lot of people. It is why we have alternatives, luckily in the form of Devuan, which still adheres to modularity.

You know when you read about OSX/MacOS or Windows having some issue, that is what systemd has become to me. Same level of can not even surprise me at this point, same level of "it happens to someone else".
But it is a little more annoying that than, because it inflicts itself in places it shouldn't be, in ways it shouldn't. No? Guess we are all just fine then…

 

[tigerroast]

I'm talking about an absolutely normal pacman update of libsystemd, systemd and systemd-sysvcompat (231-1 -> 231-3). They were the only packages being updated and running off an SSD the time window of it happening right during the update process was extremely small.

Ah, okay. Short of chalking it up to freak coincidence, I couldn't tell you what caused the issue. Sorry, man.

I was actually referring to that infamous blog post which was heavily criticized for being loaded with anti-systemd propaganda afterwards.

Yeah, there's some issues, quite valid issues, with systemd brought up in the post. Unfortunately, those criticisms were buried in a swath of the type of vitriol Slashdot shit-posters have become known for. The post is rightfully criticized.

It is a real issue, for a lot of people.

Hasn't been an issue for Facebook or Red Hat thus far.

Even for regular people, it hasn't been a problem in the year the bug existed to the point where people the world over were hitting up Debian's BTS or even systemd's Github over system hangs regarding systemd.

It is why we have alternatives, luckily in the form of Devuan, which still adheres to modularity.

It's been, what, 2 years since I've followed the Great Schism left in systemd's uptake, and no one's proven how systemd's not modular. Matter of fact, this year's systemd.conf was quite interesting in that regard. Would systemd be within this ballpark if it weren't?

Also, you just reminded me of something you said when I was still lurking. I don't remember what thread I saw you claim this, and I don't even remember if this is exactly what you said, so bear with me. I just know you said something to the tune of systemd not being modular or monolithic. Or you claimed it was monolithic and moved the goalposts. Is it safe to say that you didn't budge since?

You know when you read about OSX/MacOS or Windows having some issue, that is what systemd has become to me. Same level of can not even surprise me at this point, same level of "it happens to someone else".

This is another systemd trigger point I don't get either. Systemd actually has a pretty clean record regarding security issues, but every time a bug makes a splash, the comparisons to X.org or Windows come and the "dump ShitstemD" signs follow. No one wants to dump the Linux kernel over its security issues (which may have actually helped in the Panama Papers leak, can't cite a source for that claim, it's just something I briefly heard on LAS/Jupiter Broadcasting one day).

 

[Letalis Sonus]

Ah, okay. Short of chalking it up to freak coincidence, I couldn't tell you what caused the issue. Sorry, man.

The weirdest part was yet to come: Switching to another virtual terminal and back fixed the framebuffer so I didn't worry too much, but when I wanted to shutdown my machine later and the system switched to display the shutdown messages they were preceded by whole forum posts I wrote before and several control sequences as if all keypresses received by X were being printed there. That kinda freaked me out - I couldn't find anything in the logs, though.

 

[Linux-SWAT]

Why compare Linux and systemd ?
And why try to minor the recent systemd bug ? A user can crash the system, which is pretty critical.

 

[bzar]

Why compare Linux and systemd ?
And why try to minor the recent systemd bug ? A user can crash the system, which is pretty critical.

One shouldn't. One of those is a service manager (and an init system), the other is a kernel and in a larger context a name for operating systems based on that kernel, some of which use the former.

A user can do a lot of nasty stuff once inside a system. Typically remote exploits are considered critical, as they don't require pre-existing access to the system. Local exploits can be severe, like in the case of privilege escalation, but just crashing the system is in most cases more of a nuisance than a serious threat. Yes, it should be fixed, but it's by no means serious in a larger scale of severity.

 

[Linux-SWAT]

Well, it's not located in a browser, or some kind of fork bomb...
Anyway, that's not surprising coming from a dumb program made by a bad programmer working for a crap company ^^.

 

[TrashyMG]

So much hate, let it flow...

 

[Linux-SWAT]

Let it flow, let it flow, let it flow !

 

[ible]

A user can do a lot of nasty stuff once inside a system. Typically remote exploits are considered critical, as they don't require pre-existing access to the system. Local exploits can be severe, like in the case of privilege escalation, but just crashing the system is in most cases more of a nuisance than a serious threat.

that's not even to talk about the problem of having physical access to the system. i can stop all the running processes by pressing reboot, even the kernel and systemd. i didn't realize how severe this was until now.