Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment: My biggest concern about systemd is not technical (Score 1) 928

by tkotz (#48281805) Attached to: Ask Slashdot: Can You Say Something Nice About Systemd?
Their image as an embrace and extend project. And more concernedly that they don't care that they are viewed this way. The big problem here that they could easily fix is breaking up their source repository into multiple smaller projects. I think the best example of this is "systemd-"consoled.  Now don't get me wrong I like consoled a lot. It looks like a great next gen production of kmscon. Which I also though was a really good innovation project. But there is no good reason it should be in the systemd git repo. systemd obiously doesn't need it and it doesn't need to be any more tightly integrated with systemd than X11 or mariadbd does.

They don't care that they are perceived as not understanding the importance of keeping things as loosely coupled as possible.

I guess the alternative is you look at the systemd repo as the whole Redhat system stack with the ability to pull out the subcomponents you want, but you are really taking part of a whole distro not one of many separate services. And it will be supported as such.

Comment: My second biggest problem with systemd (Score 1) 928

by tkotz (#48281517) Attached to: Ask Slashdot: Can You Say Something Nice About Systemd?
Abandonment of classic config files and locations.The unit files are nice, but create a pretty large barrier to entry.  This has created the requirement for a lot of duplication of work and two different places in the file system to look for config info. The information in the .service files could have been added like the LSB headers to the /etc/init.d/* files.  The socket activation information could have been stored in inetd/xinetd compliant configurations with some ignorable syntax for adding named pipes and sockets. Automounts could have been parsed from /etc/auto.master. Fortunately they did this with /etc/fstab and the existing LSB headers at least.

I feel that most sys admin angst on systemd comes from the fact that they moved all the config files and created a new standard. They could have saved themselves a lot of ill will with this more backwards compatibility friendly configuration interface. instead of everything being a 20 character file name stuffed in one of the many systemd directories.

Comment: Resource Activation (Score 1) 928

by tkotz (#48281319) Attached to: Ask Slashdot: Can You Say Something Nice About Systemd?
I like that systemd combines the functionality of insserv, inetd and autofs into a single resource activation model so that whether the resource is a file, a process, an IP socket, UNIX socket or a named pipe.  It manages everything. You don't have to worry about which resource kicked off or race conditions on processes tied to multiple resources. We could get to a point where things like mysqld could be reliably started by activation from either named socket or TCP/IP without concern for race condition. It really is inetd done right.

Comment: Re:I Trust Debain (Score 1) 555

by tkotz (#48207463) Attached to: Debian's Systemd Adoption Inspires Threat of Fork
This fork is dubious. It is being proposed by people who admit to not having time to support Debian. So I doubt they will have time for a running a whole new distro.

The need for it is non-existent as Debian policy 9.3, 9.4 and 9.11 still call for the inclusion of scripts in /etc/init.d/ in all packages that provide a daemon. And LSB compliance on those scripts was a Lenny release goal. As long as they try to maintain LSB compliance as a goal and don't change the policy they will continue to support all compliant init systems. There is currently no policy for mandating that a systemd unit file be provided.

The real decision of the technical committee was that systemd is the best choice of things to call those scripts. The standardization of these files is what allowed them to make this decision at all. It would be a very strange move for Debian to suddenly start to abandon the cross init system portability it been pushing for for years. Debian has always been good at working with non default options. I know this as a KDE, ratpoison, and pre-default systemd user. And I'm currently looking at giving OpenRC a try.

The resolution just stands to tie their hands in cases that don't make sense. If a upstream wants to make their software require a certain init system, And a DD wants to package it fine. It will hurt that packages usage among people who don't use that init system. The only thing the resolution buys is political appearance.

Debian changes defaults all the time, look at the XFCE/Gnome back and forth lately. If systemd upstream starts to be too much of a problem the default will change. Probably to something that supports LSB init scripts. Systemd is on a razors edge, it barely won the vote.  Maintainers know this and won't remove a perfectly good file from their package just for the chance of getting RC bugs when the init system changes again.

Comment: Re:I Trust Debain (Score 1) 555

by tkotz (#48207451) Attached to: Debian's Systemd Adoption Inspires Threat of Fork
This fork is dubious. It is being proposed by people who admit to not having time to support Debian. So I doubt they will have time for a running a whole new distro.

The need for it is non-existent as Debian policy 9.3, 9.4 and 9.11 still call for the inclusion of scripts in /etc/init.d/ in all packages that provide a daemon. And LSB compliance on those scripts was a Lenny release goal. As long as they try to maintain LSB compliance as a goal and don't change the policy they will continue to support all compliant init systems. There is currently no policy for mandating that a systemd unit file be provided.

The real decision of the technical committee was that systemd is the best choice of things to call those scripts. The standardization of these files is what allowed them to make this decision at all. It would be a very strange move for Debian to suddenly start to abandon the cross init system portability it been pushing for for years. Debian has always been good at working with non default options. I know this as a KDE, ratpoison, and pre-default systemd user. And I'm currently looking at giving OpenRC a try.

The resolution just stands to tie their hands in cases that don't make sense. If a upstream wants to make their software require a certain init system, And a DD wants to package it fine. It will hurt that packages usage among people who don't use that init system. The only thing the resolution buys is political appearance.

Debian changes defaults all the time, look at the XFCE/Gnome back and forth lately. If systemd upstream starts to be too much of a problem the default will change. Probably to something that supports LSB init scripts. Systemd is on a razors edge, it barely won the vote.  Maintainers know this and won't remove a perfectly good file from their package just for the chance of getting RC bugs when the init system changes again.

Comment: Re:Ugh (Score 1) 727

by tkotz (#47722849) Attached to: Linus Torvalds: 'I Still Want the Desktop'
I've always been a fan of WxWidgets. Which similar to QT is an application framework, but has really good native cross platform support. It tries to not re-implement too much basic C++ stuff (for example the deprecation of wxStrings with the improvements to STL strings).

The problem with designing something from the ground up everyone can agree on is getting everyone to agree. We will see where things like OpenGL-Next and Wayland go, but legacy support is always an issue and requiring everyone to quantum switch to a new interface is tough to coordinate. If the old interface is extensible the band-aid approach gets around a lot of these issues. A better move is to start to get serious about deprecating old parts of the API while adding new parts.  This way you can transition to a completely new interface and implementation without ever completely losing consistency.

Comment: Terrible title hides lack of news. (Score 1) 155

by tkotz (#47566915) Attached to: Smoking Mothers May Alter the DNA of Their Children
Epigenitic changes are not changes in DNA, pretty much by definition.  They are the differences in gene expression caused by the chemistry of the surrounding environment. It is a fairly new field with the goal of finding the causes of differences between genetically identical subjects. The title should read, smoking expectant mothers adjust their body chemistry, possibly with long term impacts on their children's development.

Comment: Misinformation rarely helps. (Score 1) 579

by tkotz (#47370901) Attached to: Unintended Consequences For Traffic Safety Feature
The problem with this is it kind of assumes maliciousness on the part of the drivers. That they must be kept in the dark in order to make the correct decision. If the problem is that they are using walk countdown timers to incorrectly determine when the light will change. Maybe adding a countdown timer to the traffic light would give them more accurate information. If they are being distracted by trying to gather information from a pedestrian light maybe putting the information directly in front of them would help them keep focus. If they are just trying to beat the light, they are foolishly looking for an accident.

Comment: Maybe a SpreadSheet Definition Language? (Score 1) 422

by tkotz (#47121849) Attached to: Why You Shouldn't Use Spreadsheets For Important Work
I'm imagining something closer to VHDL than a traditional programming language where you primarily define connections and initial values.
It needs a way to name cells, groups of cells, contents and a way to set cell contents.
'alias' <identifier> [ '(' <parameter list> ')'] '{' <value> '}'
'set' <cell range> '{' <value> '}'
You really just need these two mechanisms, plus some extensions for formatting. A way to have set support relative addressing in the value would be nice.

# Named Cells
set A1 {"AGE}
alias age {B1}
set A2 {"Year of Birth}
alias birth_year {B2}
set A3 {"Current Year}
alias current_year {B3}

# Named Routines
alias SUBTRACT(minuend, subtrahend) {(minuend &#8722; subtrahend)}

# Simple Logic
set birth_year {1980}
set current_year {2020}
set age {=SUBTRACT(current_year, birth_year)}

# Relative addressing idea
set C1 {0}
# Previous row
set C2:C100 {=@[-1]+1)}
# Previous column
set D1:Z1 {=@[-A]*2}
# Diagonal
set D2:Z100 {=@[-A,-1]+3}

It is sort of like a language that has manual linking specification with the concurrency of VHDL. This would at least be able to be code reviewed. Redundant sets of the same cell or alias would probably be an error. That would allow for creating a dependency tree. That makes the ordering of the statements unimportant. maybe it requires aliases to be defined before use.  It wouldn't be hard to write a script that makes a spread sheet from this, but what would be better would be to add a spreadsheet plugin that lets you view this code side by side in realtime with the spreadsheet. Automatically having changes update across. and letting you use the aliases directly.

Hmm... I need to write some yacc/bison.

Comment: Re:First Tutorial I've seen with Goto... (Score 1) 143

by tkotz (#47113571) Attached to: Become a Linux Kernel Hacker and Write Your Own Module

I like that you had to do a logic inversion to make your point. You are really showing how confusing inverted logic can be. The if-else code equivalent to your goto code is:

if (a) { // Done - or log error A
}
else if (b) { // Done - or log error B
}
else if (c) { // Done - or log error C
}
else
{ ...
}

or it could be written more succinctly as:

if( !( a || b || c) ) { ...
}

"One Architecture, One OS" also translates as "One Egg, One Basket".

Working...