LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 08-21-2012, 11:11 AM   #16
philanc
Member
 
Registered: Jan 2011
Posts: 60

Rep: Reputation: 21

Quote:
Originally Posted by ruario View Post
To get some idea of the tricks you have to employ have a look at 90linux-distro (Part of os-prober, used by the Debian installer and Grub), or perhaps the detection script used by Lynis (an auditing tool for Unix), or look at "detect_distro()" within the linked script on the Compiz-Check page. Once you start looking for it you realise there are lots of scripts doing stuff like this, reinventing the wheel over and over again and detecting different selections of distros
+1 for focusing on the idea rather than on the author.

The idea itself looks good, but may have little actual value for application developers: All the great examples that you referred to show that what is needed is to check that this or that feature is available.

For example, a generic os.release file telling Opera that I run Slackware 14RC2 on my PC now would not help much. I may have not installed the complete /a to /y set, I may have installed stuff from elsewhere, etc. Am I supposed to think to change my os.release file each time I change something from the fresh Slack install? change it to what?

My guess is Opera would still have to check the actual features that matter to their apps, and couldn't do much with some arbitrary os-release file...

So yes, os-release could be used for some welcome message (as it is by systemd), and maybe to redirect me to the Slackware alley of some online app store... but beyond that I am not sure it would eliminate the sort of detection scripts listed above.

Phil
 
Old 08-21-2012, 11:26 AM   #17
zithro
Member
 
Registered: Aug 2012
Distribution: Slackware 13.37
Posts: 46

Rep: Reputation: Disabled
Why isn't this file named 'distrib-release' because it is just this ?!
So at least we could have a 'kernel-release' file, if needed in the future (or if already existing, sry for noobness).

And why not modifying uname, by adding a distro switch ? UNIX backward compat ?
 
Old 08-21-2012, 01:32 PM   #18
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,476

Rep: Reputation: 531Reputation: 531Reputation: 531Reputation: 531Reputation: 531Reputation: 531
If the idea of /etc/os-release is a freedesktop standard/proposal, I see no harm in adding such a file to Slackware.

Regardless of whether a certain person continues his Quixotic quest to become a blanket party candidate, remember that even a blind hog finds an acorn every once in a while.
 
2 members found this post helpful.
Old 08-21-2012, 02:06 PM   #19
Celyr
Member
 
Registered: Mar 2012
Location: Italy
Distribution: Slackware+Debian
Posts: 314

Rep: Reputation: 77
I don't like the idea of application behaving in a different way on different distributions. So in my opinion there is no point in /etc/os-release. I know that this may end-up in a more difficult develop but this is going to be abstraction upside-down. Distribution have to ensure standards and applications have to rely on them.
I'm not going to say that /etc/os-release is harmful but also I don't want to see distro-specific applications, I think that the model of develop that this concept is advertising it's pretty dangerous.
 
Old 08-21-2012, 02:22 PM   #20
bosth
Member
 
Registered: Apr 2011
Posts: 219

Rep: Reputation: 62
Quote:
Originally Posted by Celyr View Post
I don't like the idea of application behaving in a different way on different distributions. So in my opinion there is no point in /etc/os-release. I know that this may end-up in a more difficult develop but this is going to be abstraction upside-down. Distribution have to ensure standards and applications have to rely on them.
I'm not going to say that /etc/os-release is harmful but also I don't want to see distro-specific applications, I think that the model of develop that this concept is advertising it's pretty dangerous.
As long as distros install stuff into different locations and configure things differently, developers are going to have to take these differences into account (i.e. behave differently on different distributions). /etc/os-release seems like a reasonable way for a developer to check what is being worked with.
 
1 members found this post helpful.
Old 08-21-2012, 02:34 PM   #21
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.0
Posts: 2,242

Rep: Reputation: 614Reputation: 614Reputation: 614Reputation: 614Reputation: 614Reputation: 614
Quote:
Originally Posted by Celyr View Post
I don't like the idea of application behaving in a different way on different distributions. So in my opinion there is no point in /etc/os-release. I know that this may end-up in a more difficult develop but this is going to be abstraction upside-down. Distribution have to ensure standards and applications have to rely on them.
I'm not going to say that /etc/os-release is harmful but also I don't want to see distro-specific applications, I think that the model of develop that this concept is advertising it's pretty dangerous.
It can be useful for a .run installer, for example, to determine the distribution it is currently running on to produce a proper installable package. If a .run installer is generating .deb files in Slackware, then it has obviously failed (and while it may be possible to override such things via arguments, it isn't ideal). A package may also determine which init scripts/files to use based on the distribution (/etc/init.d/, /etc/rc.d/, systemd, etc.). I don't see a problem with the idea, but Poettering's explanation for it is, once again, brash. I can see the extensibility, touted as a feature, becoming a source of fragmentation. I can also see this simple idea ballooning, becoming a source of other system configurations...

As usual it appears that Lennart is over-complicating a good idea. I am not opposed to the file's inclusion but is it really necessary to allow ANSI colouring?
 
Old 08-21-2012, 03:36 PM   #22
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,806

Original Poster
Rep: Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810
Quote:
Originally Posted by allend View Post
No offence ruario, but you work for a commercial company that wants users to make use of social networking and cloud computing. Providing accessible information about private computing setups just creates more potential fields for data mining.
None taken. Personally I am pushing this because it would make my job (I'm a QA) easier. Nobody asked me to try and get distros to adopt this. In fact I doubt most of my colleagues are even aware of it.

Yes, I see your point that more could potentially be collected but all I want it for is crash and bug logs. These are uploaded in plain text which the user is free to edit.

Quote:
Originally Posted by brianL View Post
How many non-Slackware using developers write software for Slackware? Not many, if any?
That is not a reason to make it harder for them to take Slackware into account.

Quote:
Originally Posted by philanc View Post
For example, a generic os.release file telling Opera that I run Slackware 14RC2 on my PC now would not help much. I may have not installed the complete /a to /y set, I may have installed stuff from elsewhere, etc.
Oh you are so very wrong!

By knowing the distro (distro version) I know the exact version of the libraries on which Opera depends and which distro I should start with when attempting to repro. That is often enough. Most people do not replace the base software with different versions and you need to have Opera's dependencies installed for it to run.

Also distro specifics often turn up weird bugs. For instance recently we noticed some users were getting a crash with the Java plugin every time, other users were not. Pretty much all the users who did see the bug were running Debian-based distros. The bug was triggered by the double symlinks that Debian's alternative system setup for the Java plugin (from the Java directory to /etc/alternatives and then a symlink from there to the mozilla plugin directory). If you only had one symlink deep (most distros) you didn't see the bug.

Quote:
Originally Posted by zithro View Post
Why isn't this file named 'distrib-release' because it is just this ?!
So at least we could have a 'kernel-release' file, if needed in the future (or if already existing, sry for noobness).

And why not modifying uname, by adding a distro switch ? UNIX backward compat ?
Why does it matter?
 
1 members found this post helpful.
Old 08-21-2012, 03:47 PM   #23
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,806

Original Poster
Rep: Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810
Quote:
Originally Posted by T3slider View Post
As usual it appears that Lennart is over-complicating a good idea. I am not opposed to the file's inclusion but is it really necessary to allow ANSI colouring?
I suspect the author of screenfetch would appreciate it.
 
Old 08-21-2012, 04:07 PM   #24
ottavio
Member
 
Registered: Nov 2007
Posts: 312

Rep: Reputation: 46
I suggest that Slackware drop support for Lennart Poettering.
 
5 members found this post helpful.
Old 08-21-2012, 04:08 PM   #25
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,806

Original Poster
Rep: Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810
Quote:
Originally Posted by ottavio View Post
I suggest that Slackware drop support for Lennart Poettering.
and your thoughts on this specific suggestion are?
 
1 members found this post helpful.
Old 08-21-2012, 04:12 PM   #26
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Gentoo
Posts: 15,414
Blog Entries: 2

Rep: Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995Reputation: 3995
So it helps developers and, in its nature as a simple text file, doesn't cause anything harmful/intrusive.
I see no serious reason why not to include that.
 
Old 08-21-2012, 04:56 PM   #27
fatalfrrog
Member
 
Registered: May 2011
Distribution: Slackware
Posts: 43

Rep: Reputation: 15
http://xkcd.com/927/

At least /etc/os-release seems to be sane enough.
 
1 members found this post helpful.
Old 08-21-2012, 05:29 PM   #28
philanc
Member
 
Registered: Jan 2011
Posts: 60

Rep: Reputation: 21
Quote:
Originally Posted by ruario View Post
Oh you are so very wrong!
Good! this is the best way to learn something!

Quote:
By knowing the distro (distro version) I know the exact version of the libraries on which Opera depends and which distro I should start with when attempting to repro. That is often enough. Most people do not replace the base software with different versions and you need to have Opera's dependencies installed for it to run.

Also distro specifics often turn up weird bugs. For instance recently (...)
Interesting. Thanks for having taken the time to explain.

So, +1 for /etc/os-release inclusion, given the benefits.

Phil
 
Old 08-21-2012, 06:23 PM   #29
Eternal_Newbie
Member
 
Registered: Jun 2005
Location: The Pudding Isles
Distribution: Slackware 13.37
Posts: 573

Rep: Reputation: 58
I'm impressed, a sensible and reasonably well-thought out idea from Lennart Poettering. But as they say, even a broken clock shows the right time twice a day.

However, like zithro I think "distrib-release" or "distro-release" would be a more apt name for the file. And like allend I wonder what it might mutate into, given Poettering's history, and how long it will be before it is suddenly deprecated for arbitrary reasons.

Last edited by Eternal_Newbie; 08-21-2012 at 06:24 PM. Reason: spleng
 
Old 08-21-2012, 10:28 PM   #30
the3dfxdude
Member
 
Registered: May 2007
Posts: 315

Rep: Reputation: 84
I read this proposal from Lennart some time ago. (Although it isn't a proposal, but a justification because the decision had already been made to exclude everything else). I remember then that I thought that he was trying to solve something that shouldn't be used in the way he was solving because it can destroy portability.

Now I see this topic of discussion, and take a brief look at what Lennart was saying, and see an attempt to change something that was simple and straight-forward with yet more rules, and yet another implementation. So I guess that everyone else that doesn't have a narrow focus and wants to maintain compatibility will need to have at least four different ways just to get a piece of data. I know of a similar situation as some company who has a team defining more rules on the form of data when it is the same data as it was before. They define the requirement, but take no part in the implementation, so they have no idea the havoc they just created. Then there's no saying that it won't change again.

So my humble opinion is, again, don't give credence to Lennart's work and walk away, and rethink the problem you are solving to not depend this unreliable piece of data he was trying to standardize. There is absolutely no meaningful way you are going to handle enough cases to do anything meaningful, even if it was provided in the same form every time.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Slackware 8.1 minimum install (including KDE) JaymzCobain Slackware 11 02-03-2004 07:09 AM


All times are GMT -5. The time now is 09:57 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration