Thanks for bringing this up. The issue is already known: https://bugs.devuan.org/db/19/190.html

Are you on jessie or ascii? And could you post your sources.list?

Using apt-get dist-upgrade usually solves that kind of problem for me.

FYI: https://blogs.gnome.org/mclasen/2014/06 … me-for-gtk

Right. I already noticed this is causing problems when, at one point, the script would not exit the window manager even though I had put all remaining windows on the ignore list. The reason was that one text editor window I was running had a 5-digit process id.

After searching the web for a bit, I found a really neat solution, allowing me to go back to using the initial cut command. As mentioned above, the problem with cut is that it cannot collapse multiple spaces into single ones. But you can have tr do that before you pipe the output to cut:

wmctrl -l -p | tr -s ' ' | cut -d ' ' -f 3

tr -s, as the manual page states, "replace(s) each input sequence of a repeated character (...) with a single occurrence of that character."

It is a bit strange indeed. Thanks for spotting that.

The problem seems to have two causes: First, the second column of wmctrl's output, which displays the number of the virtual workspace a window is on, has a different width for sticky windows (those that are visible across all workspaces), since they are identified by a value of -1. (The same goes for windows with a workspace number above 10.)

Then, as ralph.ronnquist has already pointed out, cut -d " " doesn't seem to collapse multiple spaces into one. What it seems to do instead is a bit weird: If there is only one space between two printable character strings, it obviously takes that space as a delimiter, e.g.:

$ var1="one two"
$ echo "$var1" | cut -d " " -f 1
one
$ echo "$var1" | cut -d " " -f 2
two

But if there's more than one space, cut seems to count the first one as a delimiter only, but the following ones each as both a delimiter and a field, so:

$ var1="one   two"  # 3 spaces inbetween
$ echo "$var1" | cut -d " " -f 1
one
$ echo "$var1" | cut -d " " -f 2  # will print the 2nd space

$ echo "$var1" | cut -d " " -f 3  # will print the 3rd space

$ echo "$var1" | cut -d " " -f 4
two

There seems to be no way to have wmctrl not show the second column, so the script should rather use sed with a regular expression instead of cut there. I'll change that.

The script has already seen a good deal of changes since my initial post, mainly because I found out I was making some structural mistakes. I'll try to get it into a presentable shape as soon as possible, put it on GitHub and post a link on this forum.

Because you don't want to be warned about that conky window, right? A list of programs to ignore can be provided through command line parameters.

They will be handled like any other remaining window.

Can you give an example? I know that xmobar, which I use for system monitoring, is not recognized as a window by wmctrl. But that's the way I'd want it anyway.

Openbox actually has that. It asks for confirmation before it exits (unless you run openbox --exit directly). My issue with that is: If there are no remaining open windows (of possible interest), I don't want to be asked for confirmation. However, if there are, I want to be warned about that. In my experience, that really makes a difference.

Thanks for the hint. I've looked into that and it's really a far better idea and a lot easier than what I was going to try. (I would have used a live system to work on the disk, though.)

I wouldn't dare doing anything like that without a backup.

Ok, I checked this.

For the terminal started directly calling /usr/bin/urxvt, the output is:

WM_CLASS(STRING) = "urxvt", "URxvt"

If I run x-terminal-emulator, I get:

WM_CLASS(STRING) = "x-terminal-emulator", "URxvt"

I'm unsure what to make of this, however.

IIRC, you shouldn't actually have to deactivate the repo again, as nothing should be pulled from backports automatically, except for updates of those packages you've installed from that source. Maybe someone can confirm that.

Very interesting, especially the Control Center and OB Menu Generator scripts! I've been thinking a lot about putting together a clean and lean desktop environment around Openbox lately and these things look very inspiring. Unfortunately, I still lack any serious programming skills. Also, I would not be able to use Yad, since the list of design dogmas I've come up with so far includes "Thou shalt have no GTK3 UI".

But contrary to weebly, "Git-hubaloo" let's you navigate the site without having to allow third-party (or any) Javascript code to be executed and also offers version control and collaboration features, which is very useful.

I suppose, the best way to communicate that would be putting the code under an appropriate license. You could maybe use the WTFPL if that suits your taste.

As good as your intentions appear to be, I think you've kind of put your foot in it with this ad.

To be honest, I find it amusingly off, which is why I've chosen to reply in the end. (I was going to ignore the whole thing at first.) So, let's evaluate this – at least some of it.

As a preliminary remark: If at any point I should come across a bit cynical or nitpicky, don't take offense. I'm just trying to clarify what's wrong with your approach to the best of my knowledge (some of it newly acquired while writing this).

1. "I boot classically"

What's that supposed to mean? Presumably, using SysVinit. But Devuan is not about booting classically, it's about booting reasonably. Therefore, it's not about using SysVinit in particular, but about offering the freedom not to use systemd and, ultimately, to use a variety of reasonable init systems. As a first step towards that, OpenRC will be available as an alternative to SysVinit through the expert install in ASCII.

And then, booting also involves a bootloader, doesn't it? Devuan, like most Linux systems these days, uses GRUB. And while it's also possible to use something else, there'd be some tinkering involved there. But, maybe, after init freedom there comes bootloader freedom (by way of a menu to select from in the Debian Installer). Anyway, you'd probably tread on quite some people's toes going out and suggesting that GRUB is the classic Linux bootloader. Before it, there was LILO, which had been the de-facto standard bootloader for Linux systems from the release of Linux 1.0 in 1994 up until the early 2000s. Additionally, there are a bunch of other bootloaders available for Linux systems, SYSLINUX (which is actually a bundle of different bootloaders) being one of the more prominent ones.

2. "I use SysVinit"

See above.

3. "I browse the internet"

First, it should be "browse the web", not the "the internet".

The second problem here is that you're advertising Firefox as Devuan's way of browsing the web. Despite Firefox being part of the default desktop installation, this is not the best idea – for two reasons. First, there are at least five other (graphical) browsers in the package repositories for Jessie and some people might occasionally choose to use a console browser like Lynx or w3m. And second, quite some people involved with Devuan are seeking refuge from what Firefox has become (including me). There has been some discussion about this on this forum, too. For example, see:

• Life after Firefox – https://dev1galaxy.org/viewtopic.php?id=672

• The hunt for a good browser 2017 edition – https://dev1galaxy.org/viewtopic.php?id=1697

• Firefox Quantum – https://dev1galaxy.org/viewtopic.php?id=1728

Then, just two days ago, the documentation team has put up a list of alternative browsers – basically meaning: alternatives to Firefox and Chromium – on the Friends of Devuan Wiki.

3. "I am always new and secure"

I would never trust any operating system vendor telling me that the system they provide is "always new and secure". Luckily, the Devuan project has never done that and I'm pretty sure it never will. Why? Because there's something fundamentally wrong with making such a claim. Everybody who knows a few bits about software – and believe me, I'm really not an expert – also knows that there is no such thing as "always secure". While Devuan's current stable release is very stable from what I can tell, this doesn't make it secure per se. Security depends very much on how responsibly you run a system. Also, there's no fits-all solution to make a system secure, because, one, there are several aspects to security that might not be able to coexist easily, two, the meaning of "secure" may vary across different use cases.

Additionally, being "always new _and_ secure" is kind of self-contradictory. There's a reason that, for example, Debian has an unstable, a testing and a stable branch. And that reason obviously is that new software, especially when it is supposed to work smoothly in an environment as diverse as a general-purpose or "universal" operating system, often needs extensive testing.

Generally, I'd say that being new is not a reasonable category for evaluating software at all. What really counts for software is, I think: being mature and stable, getting things done efficiently and getting bug fixes deployed in proper time. (Ok, you might, for what it's worth, consider the latter as a form of being "always new" as long as there are bugs to fix.)

And if there's one thing you can definitely name a drawback of using Devuan, it is that the software packaged for the stable release is rather dated. For example, nano 2.2.6, which is in Devuan Jessie, doesn't even have the undo/redo functionality that was introduced with version 2.4 in March 2015. This is because creating and maintaining a fork is a time-consuming effort. However, this doesn't mean Devuan will always drastically lack behind. Further optimization might bring it pretty close to Debian's release cycle in the future. This is already evident if you compare the length of the time period between the release of Debian 8.0/Jessie and the Devuan 1.0.0./Jessie beta to that between the release of Debian 9.0/Stretch and the Devuan 2.0.0/ASCII beta: Debian 8 was released in late April 2015, the Devuan 1.0.0 beta release followed 19 months later, on the 1st of December 2016. Debian 9 was released in mid June 2017 and, this time, the corresponding Devuan 2.0.0 beta followed only 8 months later on the 14th of February, which is already less than half the time it took to put out the Jessie beta.

By the way, Devuan's software not being "always new" is also pretty much exactly the reason why you would download the latest and greatest version of LibreOffice from their website rather than install it from Devuan's package repositories – "if you're a technology enthusiast, early adopter or power user", that is. But if you do that in a presentation, you should seize the opportunity to demonstrate how to handle these things correctly, which would include getting the checksums and PGP signature for the package you've dowloaded and verifying it before you execute it. (They are clevery hidden under the "Info" link beneath the yellow "DOWNLOAD" button.) You should actually never execute unverified software on your working system if you have a choice.

4. "I can do anything"

Bold claim. Well, it includes "I can crash badly", when you think about it. Still, you may want to insert "virtually" there and explicitly restrict that to operating systems.