Re: If Linux Is About Choice, Why Then ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Apr 08, 2017 at 12:06:19AM -0500, Richard Owlett wrote: > On 04/07/2017 08:19 PM, Patrick Bartek wrote: > >[snip] > >>Why no one looks at their project and sees the people > >>involved when making a statistic up for the amount of dissatisfied > >>systemd users I don't know. > > > >That's an argument for another day. > > Back when the systemd FLAME WAR was prominent, I followed a link to > a justification link written by someone on the systemd development > team. It's much, much more complicated than that. Note that UNIX systems have been decidedly multi-user, even long before the SysV init (considerer "old" these days) even existed. So we always had multi-user: the trend is rather the other way: since everyone has his/her own gadget, complex things like desktop environments tend to do silly things spoiling the multi-user roots of UNIX. There was another widespread init (BSD), which still has its places, and which (ironically) brought things to the table which were given up by SysV (namely process monitoring). What SysV brought was some kind of modularity: you had one file per "package" instead of having one huge file you had to edit each time you changed a package. But it paid a price for that, and it could have been done much better. Personally I find SysV ugly, but in ways which could be made better. What systemd brings (mainly[1]) to the table is the decoupling of different "parts" of init: just imagine you have one service (let's say a web server) which depends on some other thing (say a file system being present via ummm... NFS, but it could be a RAID or a memory stick, you get the idea). With a SysV init you can't express that: you would have to script it explicitly. With systemd you can express that the web server is only to be started once that file system appears. So I'd rather say systemd is an adaptation to a much more volatile hardware landscape (which previously was only known in big iron) comming to the masses these days (just think USB). It corresponds to a more "dynamic" configuration. There are, of course alternative ways to skin the cat. Note that I'm a decided systemd opponent, and that might shine through the above. Feel free to correct any misrepresentation. regards [1] Yeah: a "declarative" configuration, which may be considered as a plus (less obscure side effects) or as a minus (stronger separation between "priests" and "mortals"). - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAljojh8ACgkQBcgs9XrR2kbEXwCfXyu9yeq6p9N1jrPJXqB+si+M RTEAn2cNEzBfh5h2V57FqZj4tOaap+Ix =7wUU -END PGP SIGNATURE-
Re: Sound problems (mpd, mpv mainly)
On Sat, 8 Apr 2017, kamaraju kusumanchi wrote: . . . % cat /usr/share/distro-info/debian.csv . . . 11,Bullseye,bullseye,2020-11-05 hi, can you explain why I don't have this line? I am on Jessie, but that should not matter. best regards, -- Pierre Frenkiel
Re: Sound problems (mpd, mpv mainly)
Op 08-04-17 om 09:23 schreef Pierre Frenkiel: On Sat, 8 Apr 2017, kamaraju kusumanchi wrote: . . . % cat /usr/share/distro-info/debian.csv . . . 11,Bullseye,bullseye,2020-11-05 hi, can you explain why I don't have this line? I am on Jessie, but that should not matter. What makes you think it shouldn't matter? Jessie has version 0.26 of the distro-info-data package. That line must have been added in a later version. Stretch has 0.33 and jessie-backports 0.32~bpo8+1. Regards, Frank
Re: If Linux Is About Choice, Why Then ...
Le nonidi 19 germinal, an CCXXV, to...@tuxteam.de a écrit : > So we always had multi-user: the trend is rather the other way: > since everyone has his/her own gadget, complex things like desktop > environments tend to do silly things spoiling the multi-user roots > of UNIX. We agree on that. > Note that I'm a decided systemd opponent, and that might shine > through the above. Feel free to correct any misrepresentation. I would not have guessed. But you forgot a very important information: what are you a PROponent of? A lot of people are only opponents, and very vocal ones, and discussing with them is usually useless; I have seen the symptoms on this very list. Being an opponent is easy, everything has flaws that can be attacked; being a proponent is harder. Now, back to the discussion at hand, namely a comparison between systemd and the SysV init system: > Personally I find SysV ugly, but in ways which could be made better. > > What systemd brings (mainly[1]) to the table is the decoupling of > different "parts" of init: just imagine you have one service (let's > say a web server) which depends on some other thing (say a file > system being present via ummm... NFS, but it could be a RAID or a > memory stick, you get the idea). With a SysV init you can't express > that: you would have to script it explicitly. With systemd you > can express that the web server is only to be started once that > file system appears. > > So I'd rather say systemd is an adaptation to a much more volatile > hardware landscape (which previously was only known in big iron) > comming to the masses these days (just think USB). It corresponds > to a more "dynamic" configuration. This is true, and IMHO a balanced way of expressing things. But you forgot a very important side to the question, that IMHO makes SysV init unsalvageable: the init program, the one running as PID 1, itself. With the SysV init system, the init program is stupid: it starts the master script that spawns all the individual init scripts, it reaps its children dutifully, but it does not keep track of anything beyond a single 3-bits piece information called "runlevel". Well, that is not entirely true: the init program can keep track of a few specific children, defined in /etc/inittab with the "respawn" keyword. But this feature is so limited and fragile that I have only seen used to respawn gettys. So, imagine you have an init script that starts, say, Apache httpd: httpd double-forks and is adopted by PID 1. At some points later, the httpd process exits; PID 1 reaps it, and that is all. Did it crash? Was it stopped by the sysadmin? Is it completely stopped, or is there still a mad subprocess running and monopolizing port 80? Nobody knows. On the other hand, systemd keeps track. When httpd is started, systemd knows "this is the httpd main process". Even better, it keeps track of all the subprocesses started by it. If the main process exits, systemd detects the return code, detects whether it is a crash or an explicit shutdown, and logs it accordingly. This makes a huge difference. Of course, a lot of other init systems came along to try and address that particular issue: daemontools, upstart, runit, etc. I have not examined all of them very closely, but I am quite sure that any of them is hugely better than SysV init. But the arguments to compare them with systemd are not all the same. That is why knowing what you are a proponent of is so important. As far as I know, systemd is the one that makes the most use of the new mutant powers of the Linux kernel: cgroups, namespaces... That makes the whole thing more complicated, but that is what makes it possible to implement certain features. For example, I have mentioned keeping track of all the subprocess started by a daemon: I do not know if that would have been possible without cgroups. And of course, there are non-technical considerations. If there is a technically awesome program but nobody uses it, maybe it is more efficient to choose a slightly-less-awesome program for which integration is already done and help is easier to find. That may not be fully satisfactory, but not all battles are worth fighting. This consideration makes a significant malus for init systems maintained by a single developer with some help of her or his mailing-list friends. And a significant bonus for init systems backed by a big corporation, even if that gives it the awful taste of a corporate program. On the non-technical side, having a non-obnoxious person as project leader can definitely be counted as a plus. That is definitely not a plus in the systemd (nor daemontools) column; I do not know for the others. Regards, -- Nicolas George signature.asc Description: Digital signature
Re: If Linux Is About Choice, Why Then ...
On 08/04/17 08:15, to...@tuxteam.de wrote: [1] Yeah: a "declarative" configuration, which may be considered as a plus (less obscure side effects) or as a minus (stronger separation between "priests" and "mortals"). If a systemd unit for a particular service needs the attention of an expert in order to be robust, the SysV-style RC script for the same service probably also needs the attention of an expert in order to be robust. As such, I find your suggestion that declarative configuration causes 'stronger separation between "priests" and "mortals"' more than a little bit questionable.
Re: If Linux Is About Choice, Why Then ...
Le nonidi 19 germinal, an CCXXV, Martin Read a écrit : > If a systemd unit for a particular service needs the attention of an expert > in order to be robust, the SysV-style RC script for the same service > probably also needs the attention of an expert in order to be robust. > > As such, I find your suggestion that declarative configuration causes > 'stronger separation between "priests" and "mortals"' more than a little bit > questionable. I think Tomás is perfectly aware of that, and quoted that argument from systemd opponents without making it his own. But you raise an interesting point. The people who invoke that argument do not realize that they are already experts, "priests", of the shell scripting language. I think that explains some of the most vocal systemd opposition: systemd aims to get rid of the scoriae of the past, but since it is IMHO somewhat over-engineered, it has a learning curve that is rather steep at the beginning. People who painstakingly learned the specifics of shell scripts and init scripts are afraid that their skill will lose value or become obsolete and they will need to start again. Regards, -- Nicolas George signature.asc Description: Digital signature
Re: If Linux Is About Choice, Why Then ...
On 2017-04-08 at 05:56, Nicolas George wrote: > Le nonidi 19 germinal, an CCXXV, Martin Read a écrit : > >> If a systemd unit for a particular service needs the attention of >> an expert in order to be robust, the SysV-style RC script for the >> same service probably also needs the attention of an expert in >> order to be robust. >> >> As such, I find your suggestion that declarative configuration >> causes 'stronger separation between "priests" and "mortals"' more >> than a little bit questionable. > > I think Tomás is perfectly aware of that, and quoted that argument > from systemd opponents without making it his own. > > But you raise an interesting point. The people who invoke that > argument do not realize that they are already experts, "priests", of > the shell scripting language. > > I think that explains some of the most vocal systemd opposition: > systemd aims to get rid of the scoriae of the past, but since it is > IMHO somewhat over-engineered, it has a learning curve that is rather > steep at the beginning. People who painstakingly learned the > specifics of shell scripts and init scripts are afraid that their > skill will lose value or become obsolete and they will need to start > again. With the additional factor that expertise in shell is useful in multiple contexts, but (AFAIK, though I'm not an authority here) expertise in systemd unit files et al. is useful *only* in the context of systemd - with the result that the former is both more rewarding to learn, and more likely to be already known by someone who is new to what might be called 'sysadmin work'. (Though there's something to be said for a new-to-the-problem-domain person starting from zero rather than having to unlearn things that may be useful in other problem domains but aren't advisable in this one.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Sound problems (mpd, mpv mainly)
On Sat, 8 Apr 2017, Frank wrote: What makes you think it shouldn't matter? Jessie has version 0.26 of the distro-info-data package. That line must have been added in a later version. Stretch has 0.33 and jessie-backports 0.32~bpo8+1. you are right: installing version .33 actually gives the line with version 11. Nevertheless, I don't see why this package is not upgraded in Jessie: it just gives a list, and have then no dependency problem. best regards, -- Pierre Frenkiel
Re: If Linux Is About Choice, Why Then ...
writes: > > What systemd brings (mainly[1]) to the table is the decoupling of > different "parts" of init: just imagine you have one service (let's > say a web server) which depends on some other thing (say a file > system being present via ummm... NFS, but it could be a RAID or a > memory stick, you get the idea). With a SysV init you can't express > that: you would have to script it explicitly. With systemd you > can express that the web server is only to be started once that > file system appears. > > So I'd rather say systemd is an adaptation to a much more volatile > hardware landscape (which previously was only known in big iron) > comming to the masses these days (just think USB). It corresponds > to a more "dynamic" configuration. > > There are, of course alternative ways to skin the cat. > > Note that I'm a decided systemd opponent, and that might shine > through the above. Feel free to correct any misrepresentation. > You've been perfectly fair. Would that all opponents did so. As Nicolas said, systemd's main advantage is that it keeps better track of what exactly it launches. Not only can it keep track of subprocesses launched by the main process, it can also use that knowledge to manage their resources, giving the sysadmin the power to constrain a service so that it never eats up all system resources. Or, by putting it in a separate scope, it can separate processes from the user session that started them, making clear the difference between a rogue process that should have died on logout, and a user service that should persist across sessions. The bad news on that last one is that it triggered another flamewar, as the default chosen (kill all processes on user session end) was rather unfriendly to programs like tmux and screen. Mart -- "We will need a longer wall when the revolution comes." --- AJS, quoting an uncertain source.
Re: Excel shared spreadsheets on samba file server
Dante F B Colò wrote: > Hello everyone > > I 'm trying to find what it happens on my Samba AD servers especially > with shared spreadsheets, my personal opinion this feature on Excel is > crap and unreliable but many people use it, how does Samba currently > behave with this ? Is someone experienced any problem with this ? > Frequently happens changes made by other user are lost the spreadsheet > opens as read only , the shares are all using vfs_acl_xattr module to > mimic NTFS permissions, clients are all windows machines versions 7 and > 10 , i upgraded samba 4.3.11 to 4.5.7 but both have the same behavior. > Any ideas ? Working as designed. When a user opens a file, it is locked for editing by that user. No one else can modify it. If you need true multi-user access, a database is probably a better approach. -- |_|O|_| Registered Linux user #585947 |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
Tuning boot time of my server
Hello, just for sports, I tried to minimise the boot time of my server, which is running systemd. I have one mayor blocker: % systemd-analyze blame 10.746s srv-share-backup.mount 10.258s nfs-kernel-server.service 3.311s mysql.service 1.444s apache2.service 1.344s epgd.service 1.012s privoxy.service /srv/share/backup lives on a Western Digital WD RED, and this device takes ages to spin up. So I'd rather /not/ spin this disk, if it is not necessary - which it isn't. That's why I've set up an automount unit for it. Now I don't understand why it is mounted on booting. /srv/share/backup is exported via NFS, which might be the reason for the slow nfs-kernel-server.service. But I have other exports on WD REDs as well, and they are not mounted while booting. So why is srv-share-backup.mount started at boot-time? It's not wanted or directly enabled: % find /etc/systemd -type l -iname \*.mount /etc/systemd/system/local-fs.target.requires/-.mount /etc/systemd/system/local-fs.target.wants/boot.mount /etc/systemd/system/dev-disk-by\x2duuid-10ad4727\x2d658c\x2d4559\x2d90b3\x2dfd966f8dbf96.device.wants/boot.mount Can you give me a hint? I've attached the tiny output of "systemd-analyze plot " for your reference. -- Markus Grunwald http://www.the-grue.de/~markus/markus_grunwald.gpg zem-boot.svg.xz Description: application/xz
Re: Tuning boot time of my server
Le 04/08/17 à 21:15, Markus Grunwald a écrit : > Hello, > > just for sports, I tried to minimise the boot time of my server, which > is running systemd. I have one mayor blocker: > > % systemd-analyze blame > 10.746s srv-share-backup.mount > 10.258s nfs-kernel-server.service > 3.311s mysql.service > 1.444s apache2.service > 1.344s epgd.service > 1.012s privoxy.service > > > /srv/share/backup lives on a Western Digital WD RED, and this device > takes ages to spin up. So I'd rather /not/ spin this disk, if it is > not necessary - which it isn't. That's why I've set up an automount > unit for it. > Now I don't understand why it is mounted on booting. /srv/share/backup > is exported via NFS, which might be the reason for the slow > nfs-kernel-server.service. But I have other exports on WD REDs as > well, and they are not mounted while booting. > > So why is srv-share-backup.mount started at boot-time? It's not wanted > or directly enabled: > > % find /etc/systemd -type l -iname \*.mount > /etc/systemd/system/local-fs.target.requires/-.mount > /etc/systemd/system/local-fs.target.wants/boot.mount > /etc/systemd/system/dev-disk-by\x2duuid-10ad4727\x2d658c\x2d4559\x2d90b3\x2dfd966f8dbf96.device.wants/boot.mount > > Can you give me a hint? I've attached the tiny output of > "systemd-analyze plot " for your reference. > > -- > Markus Grunwald > http://www.the-grue.de/~markus/markus_grunwald.gpg > For my servers the longest time by far is when the firmware (BIOS or EFI begins and tests evrything), not the boot itself, except on old Redhat which waited before really starting and had no parrallel boot. Debian boot time with or without systemd can be neglected, especially for servers who boot not more than twice a year.
Re: Tuning boot time of my server
Am 08.04.2017 um 21:15 schrieb Markus Grunwald: > Hello, > > just for sports, I tried to minimise the boot time of my server, which > is running systemd. I have one mayor blocker: > > % systemd-analyze blame > 10.746s srv-share-backup.mount > 10.258s nfs-kernel-server.service > 3.311s mysql.service > 1.444s apache2.service > 1.344s epgd.service > 1.012s privoxy.service > > > /srv/share/backup lives on a Western Digital WD RED, and this device > takes ages to spin up. So I'd rather /not/ spin this disk, if it is > not necessary - which it isn't. That's why I've set up an automount > unit for it. > Now I don't understand why it is mounted on booting. /srv/share/backup > is exported via NFS, which might be the reason for the slow > nfs-kernel-server.service. But I have other exports on WD REDs as > well, and they are not mounted while booting. > > So why is srv-share-backup.mount started at boot-time? It's not wanted > or directly enabled: Most likely something is accessing the share, which trigger the mount request. One possible candidate could be nfs-kernel-server. If you stop exporting the share via NFS, is it still (auto)mounted? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Tuning boot time of my server
Hello Erwan, > Debian > boot time with or without systemd can be neglected, especially for > servers who boot not more than twice a year. That's why I wrote: > > just for sports, I tried to minimise the boot time of my server, which > > is running systemd. I have one mayor blocker: -- Markus Grunwald http://www.the-grue.de/~markus/markus_grunwald.gpg
Re: If Linux Is About Choice, Why Then ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Apr 08, 2017 at 11:07:32AM +0200, Nicolas George wrote: > Le nonidi 19 germinal, an CCXXV, to...@tuxteam.de a écrit : > > So we always had multi-user: the trend is rather the other way: > > since everyone has his/her own gadget, complex things like desktop > > environments tend to do silly things spoiling the multi-user roots > > of UNIX. > > We agree on that. Yes, this was more an answer to Richard. > > Note that I'm a decided systemd opponent, and that might shine > > through the above. Feel free to correct any misrepresentation. > > I would not have guessed. But you forgot a very important information: > what are you a PROponent of? A more evolutionary approach. A de-boilerplating of SysV and perhaps an outsourcing of process shepherding to something along the lines of runit. Definitely not a tightly coupled process set hooking into everything from DBus to cgroups. > With the SysV init system, the init program is stupid: it starts the > master script that spawns all the individual init scripts, it reaps its > children dutifully, but it does not keep track of anything beyond a > single 3-bits piece information called "runlevel". [...] All the well-known arguments in favour of systemd. I know them by heart, and this discussion has gone back and forth enough for all of us. You know the counter-arguments as well as I know the pro arguments, so I think it's no use in turning another round. Perhaps we must accept that there are different philosophies here, without hating each other :-) regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAljpRpkACgkQBcgs9XrR2kZpaACeNNLuitVVMbhY27fOik+KLBxe 764AnRJUKA+lPUgf/y5ASx6caCyd+3IA =nhSQ -END PGP SIGNATURE-
Re: If Linux Is About Choice, Why Then ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Apr 08, 2017 at 11:56:10AM +0200, Nicolas George wrote: > Le nonidi 19 germinal, an CCXXV, Martin Read a écrit : > > If a systemd unit for a particular service needs the attention of an expert > > in order to be robust, the SysV-style RC script for the same service > > probably also needs the attention of an expert in order to be robust. > > > > As such, I find your suggestion that declarative configuration causes > > 'stronger separation between "priests" and "mortals"' more than a little bit > > questionable. > > I think Tomás is perfectly aware of that, and quoted that argument from > systemd opponents without making it his own. I'm aware of that, but still make this argument (in part) my own. There is a whole spectrum between a script that "works in my environment" and a robust script, as Martin envisions, the kind you would package as part of a distribution, having to cope with very different environments. The beauty of that spectrum is that a "mere mortal" can walk this thing gradually, improving in the process. I think it's perfectly legitimate to disagree with me on that, but there you are. > But you raise an interesting point. The people who invoke that argument > do not realize that they are already experts, "priests", of the shell > scripting language. > > I think that explains some of the most vocal systemd opposition: systemd > aims to get rid of the scoriae of the past, but since it is IMHO > somewhat over-engineered, it has a learning curve that is rather steep > at the beginning. People who painstakingly learned the specifics of > shell scripts and init scripts are afraid that their skill will lose > value or become obsolete and they will need to start again. It's more: there's a huge gap between "doing what systemd allows", in its declarative language, and changing the way it works, which involves grokking the C sources. This kind of layering is what we software "engineers" do all the time, but in this case, the layer gap is far too wide for my taste. regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAljpSRoACgkQBcgs9XrR2kYaJwCfabVz/zbvHY+l9MPTGa7KhVzg iFkAn2U0f7CLJDOroBxVs2zY+IcjfQTk =ipzA -END PGP SIGNATURE-
info
hi. I am a consumer microsoft from little past to linux. but how much confusion that us. thousand distributions thousand names. it should take only a name with at the most 5 or 6 versions of desktop. will it be the monopoly microsoft that makes you divide? however my question is this: among all the desktops (kde gnome etc) which are those that have the toolbar in low or that however through formulations they allow to put her/it in low? I know the lxde because it is that what time I use. however I would want to know the situation of the other desktops regarding the position of such bar. wishes and graces. but you are united. and fairies of the files that contain all the dependences (like .exe or .mac). this way that each chooses whether to install them or rather through synaptic and connection internet or offline.
Re: Sound problems (mpd, mpv mainly)
Thanks Kamaraju, that looks awesome. So extrapolating from the pattern of the dates, i would guess that 'stretch' should be actually released on the creation date of 'buster', 2018-07-01. (And i should note, just for the record, that indeed the wikipedia article on debian versions had more information than i realized; i was just looking at the infobox at top. Thanks Pierre for reading more carefully than me!!) dan On Fri, Apr 7, 2017 at 10:19 PM, kamaraju kusumanchi wrote: > On Sun, Apr 2, 2017 at 1:14 PM, Dan Hitt wrote: >> /etc/debian_version says '9.0' for me, and i think it is called >> 'stretch' (it is not in the list of debian versions in the wikipedia, >> which stops at 8, 'jessie'). > > FWIW, you can get this information even without going to wikipedia. > > % sudo apt-get install distro-info-data > > % cat /usr/share/distro-info/debian.csv > version,codename,series,created,release,eol > 1.1,Buzz,buzz,1993-08-16,1996-06-17,1997-06-05 > 1.2,Rex,rex,1996-06-17,1996-12-12,1998-06-05 > 1.3,Bo,bo,1996-12-12,1997-06-05,1999-03-09 > 2.0,Hamm,hamm,1997-06-05,1998-07-24,2000-03-09 > 2.1,Slink,slink,1998-07-24,1999-03-09,2000-10-30 > 2.2,Potato,potato,1999-03-09,2000-08-15,2003-07-30 > 3.0,Woody,woody,2000-08-15,2002-07-19,2006-06-30 > 3.1,Sarge,sarge,2002-07-19,2005-06-06,2008-03-30 > 4.0,Etch,etch,2005-06-06,2007-04-08,2010-02-15 > 5.0,Lenny,lenny,2007-04-08,2009-02-14,2012-02-06 > 6.0,Squeeze,squeeze,2009-02-14,2011-02-06,2014-05-31 > 7,Wheezy,wheezy,2011-02-06,2013-05-04 > 8,Jessie,jessie,2013-05-04,2015-04-25 > 9,Stretch,stretch,2015-04-25 > 10,Buster,buster,2018-07-01 > 11,Bullseye,bullseye,2020-11-05 > ,Sid,sid,1993-08-16 > ,Experimental,experimental,1993-08-16 > > > > -- > Kamaraju S Kusumanchi | http://raju.shoutwiki.com/wiki/Blog
Re: info
On Sat, Apr 8, 2017 at 8:58 PM, domenico cop wrote: > hi. I am a consumer microsoft from little past to linux. but how much > confusion that us. thousand distributions thousand names. it should take only > a name with at the most 5 or 6 versions of desktop. will it be the monopoly > microsoft that makes you divide? however my question is this: among all the > desktops (kde gnome etc) which are those that have the toolbar in low or that > however through formulations they allow to put her/it in low? I know the lxde > because it is that what time I use. however I would want to know the > situation of the other desktops regarding the position of such bar. wishes > and graces. but you are united. and fairies of the files that contain all the > dependences (like .exe or .mac). this way that each chooses whether to > install them or rather through synaptic and connection internet or offline. > KDE has [at least as configured by red hat] toolbar at bottom of screen. XFCE can be easily configured that way. One catch though: I can't understand your last sentence. Can you clarify it? PS: Many distributions is actually good thing. More choice. Most of them are highly specialized anyway and cater to particular kind of user. -- darkestkhan -- Feel free to CC me. jid: darkestk...@gmail.com May The Source be with You.
Re: info
On Saturday 08 April 2017 23:12:15 darkestkhan wrote: > On Sat, Apr 8, 2017 at 8:58 PM, domenico cop wrote: > > hi. I am a consumer microsoft from little past to linux. but how much > > confusion that us. thousand distributions thousand names. it should take > > only a name with at the most 5 or 6 versions of desktop. will it be the > > monopoly microsoft that makes you divide? however my question is this: > > among all the desktops (kde gnome etc) which are those that have the > > toolbar in low or that however through formulations they allow to put > > her/it in low? I know the lxde because it is that what time I use. > > however I would want to know the situation of the other desktops > > regarding the position of such bar. wishes and graces. but you are > > united. and fairies of the files that contain all the dependences (like > > .exe or .mac). this way that each chooses whether to install them or > > rather through synaptic and connection internet or offline. > > KDE has [at least as configured by red hat] toolbar at bottom of > screen. XFCE can be easily configured that way. TDE also - yoyu can have the panel wherever you want it. > > One catch though: I can't understand your last sentence. Can you clarify > it? Ditto, sorry. Lisi
Re: If Linux Is About Choice, Why Then ...
On Sat, Apr 8, 2017 at 4:15 PM, wrote: > [...] > What systemd brings (mainly[1]) to the table is the decoupling of > different "parts" of init: just imagine you have one service (let's > say a web server) which depends on some other thing (say a file > system being present via ummm... NFS, but it could be a RAID or a > memory stick, you get the idea). With a SysV init you can't express > that: you would have to script it explicitly. With systemd you > can express that the web server is only to be started once that > file system appears. Well, sure you could express such relationships in the sysv scripts, and people did. But sysv scripts used the shell as the declaration language, and the shell is very flexible, and everyone seems to have done their own thing in expressing such relationships. That made it hard to get an overall analysis. What could have been done here was to build a simple database of relationships and a daemon to maintain the database. Sysv could start that daemon early, and other inits could simply register through that daemon as they came on-line. But there were several different approaches to that, and territory wars, and it wasn't ready for prime-time on the schedule of Fedora's management team. > [...] > [1] Yeah: a "declarative" configuration, which may be considered > as a plus (less obscure side effects) or as a minus (stronger > separation between "priests" and "mortals"). There is no plus to a restricted declaration syntax except the walls between the controlling service and the controlled services. In other words, the minus of separation is the plus of separation. And, of course, all the relationship database daemons used their own subset of the shell's syntax for the declaration syntax. Systemd uses a completely separate declaration syntax to strengthen the walls. Noting that the walls are an illusion will invite flames, but that's true of all the walls in software systems. They can all be got around. If we couldn't get around the walls, no work could be done. The issue is not the walls, it is whether processes can maintain reasonable behavior in getting around the walls and still get their jobs done, without too much policing and hand-holding from whatever daemon/service is in charge of the wall. And it was not that it could not be achieved in sysv, it was only that it had not been uniformly achieved to meet Fedora management's timetables. This was and is the core of the arguments, I believe, but, if I expand that thought too much I think it will still cause flames. (And I don't understand why. Politics is an essential part of management, and no one reasonable claims that open source means no management at all. We ultimately will have to deal with the political issues, whether we think we want to or not.) (No, wait, I guess I do understand why. We do not have a uniform language of politics. We can't say words like "democratic" or "committee" and be sure that the person we are talking to understands them they way we intend them. I should have been more careful about that then, and I will try to be more careful now, if we can do this conversation this time.) -- Joel Rees I'm imagining I'm a novelist: http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html More of my delusions: http://reiisi.blogspot.jp/p/novels-i-am-writing.html
