Slack Community call

Originally Posted by genss before it was practically impossible due to random lockups now the nouveau driver is a lot more stable but i still can't run dota2 on it (terrain does not render), and that is a requirement for me

Maybe you are missing the texture compression library.

Download and install:
http://cgit.freedesktop.org/~mareko/libtxc_dxtn/
Run

export force_s3tc_enable=true

before running the game.

done that
steam won't even start without s3tc forced

nvidia binary will support wayland some time in the future
nouveau will get good enough, some time in the future
il wait and see who's faster

Well, Bartgymnast, I'm in concern regarding two of the projects you mentioned.

A Slint's maintainer, I can hardly see the link between the internationalized installer and the init system, apart the fact that obviously an init (very simple and specific, with an /etc/inittab slightly modified in case of the internationalized installer) of course occurs when booting the installer.

The internationalized installer does add a few features (see the paragraph "Use your polyglot installer" in this page for details), all optional and that in no way can be considered major changes. I don't know whether the polyglot installer or some of its added features will eventually make their way in Slackware proper and when. I'm afraid it would be counterproductive to send more than a yearly mail to Pat requesting that, so it's the frequency that I adopted

In the Slint project when there is a change in the genuine Slackware installer we just follow suit, and that will be the case if the init system changes, but only after Pat decides it.

However if someone proposes an alternate init system and an associated new installer, I could advise how to localize it if requested as I've now a few experience doing that.

About eudev, well... the thread that I initiated is just about modifying Slackware's udev SlackBuild to build a package using as source a tarball provided by the Gentoo eudev team, so label that a project would be an overstatement.

Also, I really don't know how long extracting udev from systemd will remain reasonably feasible...

When did it become so urgent to change init systems in Slackware or anywhere? I press the power button on my laptop and it boots. It does not start in the mythical 9milliseconds that some people lay claim to, but it starts up quick enough for me. And then it runs, and it runs well.

I have nothing against alternatives, but until I hear an actual reason for changing, I don't see the point of insisting that I need a new one.

Originally Posted by notKlaatu When did it become so urgent to change init systems in Slackware or anywhere? I press the power button on my laptop and it boots. It does not start in the mythical 9milliseconds that some people lay claim to, but it starts up quick enough for me. And then it runs, and it runs well. I have nothing against alternatives, but until I hear an actual reason for changing, I don't see the point of insisting that I need a new one.

I agree that there's no good reason to switch away from init, other than most other distros doing it and future programs likely mandating it (systemd).

When I turn on my computer I just press the button, sit down, grab my drink, drink, put it down and log in. The boot time is not long enough to impede me in any way, much less warrant a sudden change in init system. If people really care that much about boot speed, then never shut down, go into suspend.

Originally Posted by dunric When speaking about Wayland, besides debates about (in)maturity of current codebase and drivers support, I've read it does not and even doesn't plan implement remote logins/sessions. How can fill this missing gap Wayland users ? I've read about NX-dervied x2go but yet not yet heard about production use.

In one of the early videos where a Wayland designer was discussing this very complaint, he pointed out that the X-org team had broken the remote session behavior and nobody bitched about it. Therefore it wasn't really needed.

Because it's a lot more important that you can drag a window without tearing than to have convenient remote graphical access. Or something.

(I don't think that I want to spare the effort to chase down that video, so feel free to call this FUD since I'm not offering the link. No, really; I may have misunderstood what the fellow was saying.)

i tried finding the video of an xorg dev explaining how inefficient X protocol is over the network
cant find it, but i did find a CCC video about X security that some might find interesting

again, no hard feelings
i know remote X is controversial

I'm guessing you were trying to find Daniel Stone's Aus. Linux Conf talk: https://www.youtube.com/watch?v=RIctzAQOe44

I dunno, I have a lot to learn about X, but it had me wondering if there wasn't a different path that might have been taken when DRI and client side fonts happened, not to mention if whether gtk and qt were to blame in some way for the stated fact that X clients are now throwing up bitmaps mostly.

That said, even emacs with athena widgets has awful latency problems with remote X. xterm works okay, but I can't think what else I'd want to use with remote X over the Internet (as opposed to on a good fast local lan).

Runit-for-LFS as a project would be willing to work on porting our Runit work to Slackware, but honestly, it will take at least a month to get the Stage scripts patterned after Slackware's schematics, and maybe another month to get the scripts publicly ready.

The good point of this is, nothing else in the system would require a rebuild. Runit-for-LFS has our own sysvinit functionality mimic programs and scripts also. Runit may need a patch to work the sv service binary by default from the correct path though. This is entirely optional.

After that, the next problem is redrafting each and every run, finish, and log script for the services over to Slackware. It is shell script friendly, so the work would flow faster so nothing new would need to be relearned.

@Bart & Didier... As far as the long term udev issue... eudev should be fully capable of working with Slackware (or any GNU/Linux) as long as the netlink communication interface isn't mucked up for kdbus, then nothing will work.

@Bart, you said four ports? Would these other ports be inclined out as Runit, systemd, bsdinit+perp, and OpenRC, or another schema?

If you don't use arrays in the script then you can use d/ash instead of bash, which makes it quicker.
Even if you do use arrays, you can still use arrays in d/ash by using the techniques which GrapefruiTgirl discovered in this thread

Originally Posted by notKlaatu When did it become so urgent to change init systems in Slackware or anywhere? I press the power button on my laptop and it boots. It does not start in the mythical 9milliseconds that some people lay claim to, but it starts up quick enough for me. And then it runs, and it runs well. I have nothing against alternatives, but until I hear an actual reason for changing, I don't see the point of insisting that I need a new one.

There may be many people (I included) who are perfectly happy with the speed and largely serial nature of the current init system.

It's equally clear that there are others who would prefer it to be faster and have more parallelization.

For the latter group you might very well ask, why don't they try another distro?

Maybe, Slackware has other features that they would prefer to stick with.

Having been involved on and off in data processing (that would be punch cards loaded into tabulator machines with jumper cables on phenolic boards for "programming") since the early sixties through early "computers" that were essentially glorified tabulators (programs on punch cards, one at a time) to real, honest-to-gosh multiuser, multitasking mainframes (Honeywell GECOS) to minicomputers (and supermini computers) to microcomputers (yeah, they used to be called that) programed by hex keyboards and flipping switches to Unix boxes to supermicro computers (huh?) to today's Linux systems that run on Wintel PCs as well as giant server farms with blades running Linux (remember the guy a couple of months ago that couldn't get all 64 cores going doing genome sequencing?) I think I may have learned a couple of things.

If it ain't broke it don't need fixing.

Keep it simple, stupid.

I've been reading (and trying to understand) systemd. Can't really see a good reason for it. init works, works well and is easy to understand and configure. I don't give a hoot if booting takes a minute, maybe a minute and a half. Unix run levels make sense to me (I tend to shut down to run level 1 when I apply updates and things). I want to see what's going on so I boot to run level 3 and use startx. I readily admit that I'm old-fashioned and don't really want everything hidden behind a pretty face -- that tends to confuse some folks when they watch my systems boot.

My opinion about the BASH mess tends to be that a lot of folks that didn't have anything better to do fixed what did not need fixing and wound up with a royal screw up.

Doug McIlroy had it exactly right decades ago, Patrick Volkerding also had it precisely right: if it don't work, don't include it.

Hope this helps some.

Originally Posted by tronayne Having been involved on and off in data processing (that would be punch cards loaded into tabulator machines with jumper cables on phenolic boards for "programming") since the early sixties through early "computers" that were essentially glorified tabulators (programs on punch cards, one at a time) to real, honest-to-gosh multiuser, multitasking mainframes (Honeywell GECOS) to minicomputers (and supermini computers) to microcomputers (yeah, they used to be called that) programed by hex keyboards and flipping switches to Unix boxes to supermicro computers (huh?) to today's Linux systems that run on Wintel PCs as well as giant server farms with blades running Linux (remember the guy a couple of months ago that couldn't get all 64 cores going doing genome sequencing?) I think I may have learned a couple of things. If it ain't broke it don't need fixing. Keep it simple, stupid.

Every time I try to convince myself using this common wisdom there is always something that bothers me. These tabulators weren't broken. And what could be simpler than a tabulator. What went wrong. How we ended up with these giant server farms with blades running Linux.

Cheers.

Originally Posted by ivandi Every time I try to convince myself using this common wisdom there is always something that bothers me. These tabulators weren't broken. And what could be simpler than a tabulator. What went wrong. How we ended up with these giant server farms with blades running Linux. Cheers.

Well, thing is, they weren't broken; they were just slow.

The first programmable computer was the Bomb developed and implemented at Bletchley Park in Milton Keynes, Buckinghamshire, England during World War II. That's where they broke Enigma. It had electronic tubes (what the Brits call valves), paper tape, lots of relays and other exotic gadgets and was operated by a lot of really smart folks led by Alan Turing.

All that's really happened is that electronics has gotten physically smaller, packed with more and more circuits that go faster and faster on less power and the price of admission has gone down exponentially over time. The basics are still the basics: load register, load other register, execute. Some guys recently (like in the last week two) have developed quantum in silicon (which wasn't supposed to be possible a month ago). Multicore processors are just more stuff on the same die for less cost still doing load register...

Anymore it's not the hardware that's the limit. Gordon Moore (in 1965!) postulated the law named for him and it's still in effect (so far, anyway). Starting to plateau, it's beginning to look like nanotubes might be the next great thing. When it was tubes and relays and miles of wire and big clunky boxes it was the programming that mattered. It still is. You could "write" bad programs on a phenolic punch board, you could write good ones. You still can -- in multiple languages with a lot of help from utilities and the shell but nobody has figured out, yet, how to create perfect systems although I believe Linux comes darned close to be a perfect platform where you get to stand on the shoulders of giants and do your thing.

The trick is to learn when to stop.

@tronayne

You know it took me some time to get used to the mouse. Since then I try to avoid judging before trying. To be able to stop you have to move first.

Cheers.