| View previous topic :: View next topic |
| Author |
Message |
mrbassie
l33t
Joined: 31 May 2013
Posts: 772
Location: over here
|
 Posted: Fri Sep 05, 2014 6:35 pm Post subject: |
 |
|
| mayak wrote: | | Fitzcarraldo wrote: | | In my opinion, [...] |
Thanks Fitzcarraldo - this is exactly how I would guess/predict the future of systemd/Linux.
I really hope there is enough manpower to keep the well-oiled GNU/Linux userland alive.
Otherwise we have to team up with the BSD guys and bring the BSD userland to Linux.
BSD/Linux so to say  |
Or just use a BSD as is. |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Sep 07, 2014 10:53 am Post subject: |
|
|
| mv wrote: | | steveL wrote: | | As for pidfiles, they're a hack, and don't actually work unless the daemon cooperates, |
Even if the daemon does cooperate, they are not reliable: The daemon can go down, and another process can get the same PID by accident. Not very likely, but possible in theory. In the very least, there is a theoretical race condition either this or that way. |
Yes, as I said, that's why cgroups were invented, and they've been around for years in Linux, long before systemd was a glimmer in someone's eye.
Sessions are a great idea too, but they're used more for shell process groups and ofc daemons traditionally fork to start a new sid. As discussed by greycat in the link I gave on PM, that hack in itself makes process supervision harder, which is why people came up with pidfiles. But if you get rid of the hack you can go back to using the OS to monitor your children. Forking to create a new sid is only appropriate during development when you're running the daemon from the command line to see what you broke. You put yourself in a new session, so you won't get terminal signals, similar to nohup
It's totally pointless during normal usage, since there is no terminal involved, and as pointed out it makes process supervision harder, which led to the lunacy of pidfiles. That's why "modern" daemons have a foreground switch, so they can do what they should have been doing all along, ie less.
Anyhow cgroups are just another layer on top of sessions, that a process cannot escape unless privileged. It means the admin can categorise the processes, essentially exposing another variant of sessions, in implementation terms (yaf category or group), and supervise the lot. I find the latter a bit troubling, in that it should have been there from the start, but I'm glad it's there now.
Pidfile are used more nowadays for locking, to ensure single instance execution. WRT recycled pids, that's why you have /proc/cmdline et al: a daemon can save off more useful info that can be used to check whether it is in fact the same instance, but again it's a hack. it's much better to see if you can contact the instance as a client, and incorporate a very simple check into your protocol for that situation, to avoid races. After all you're providing a service, typically with a UDP socket. Or you're not a daemon and what are we even discussing?
That said the fs is still the best place to synchronise long-lasting data. That's what it was invented for, as you pointed out elsewhere (that discussion made me chuckle: "what is storage?" followed by a very useful philosophical discussion.. ;) |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Sat Oct 04, 2014 5:57 pm Post subject: |
|
|
Hello forum, sorry for bumping this already old thread. However, there is a quite realistically competent replacement for systemd - the nosh package:
http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html.
I also filed a ebuild request of this on b.g.o (https://bugs.gentoo.org/show_bug.cgi?id=524314).
Some highlights:
- Designed similar to daemontools/runit/s6, plus parallelized service startup/shutdown, service interdependencies and startup/shutdown orderings, and an extensible system target mechanism.
- Interfaces quite isomorphic (yes, I understand what I say) to systemd interfaces but without the unnecessary bloats, and a mechanism for converting systemd "unit" files (within certain limits that should cover the majority of units) to "service bundles".
- An abundance of "shims" to systemd/upstart/sysvinit (optional and loosely coupled).
- Optionally supports the heavily boasted "socket activation" mechanism.
- Uses nosh, a language similar to execline but even simpler, for "run" scripts.
- Portabiliy to BSD and other Unix-like platforms.
Finally, as a disclaimer, I am not affiliated with the developers of nosh, but seriously concerned about the Linux ecosystem going in an undesirable direction in current "init war". Here I am merely suggesting a possibly new and decent choice, in the hope that this might help to increase public awareness and development interest of nosh, and contribute to a healthier competition in the field of init/supervision; nor am I trying to force the choice upon anyone (in fact I myself still feel sceptical about its use of C++, and will still stick to OpenRC in foreseeable future).
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Thu Dec 18, 2014 10:22 pm Post subject: What does PID 1? |
|
|
Very intersting dicussion to say the least.
@skarnet:
What does PID 1, let's call it init, for you? s6 seems promising and a bit cumbersome at the
same time.
First, what does PID 1? You raised multiple good reasons to make s6 interesting, but it
looks like it's not clear, for a user stand point, regarding what should PID 1 do. When I took a
look on s6, I was like... where's the binary that I should use as PID 1 to append to `init=...'
and what does that binary to begin with... I was rather confused.
Your response (at least what I've found): There's no clear response on what to append to `init=',
this is a implementation choice. It should handle stage 1 (boot) and stage 3 (shutdown/reboot) and
leave stage 2 to `s6-svscan'. So to the question what's PID 1: it's something, not entirely defined,
that should handle system initialization, system shutdown and service management.
I believe that this design is flawed because PID 1 should only be the parent of the entire processes
tree and leave system power up/down and service management to other PID(s). This is a saner
approach which ensure by _design_ that PID 1 will _never_ die. And this what runit-init does by
design and leave the task of managing services to another process.
Second, s6 installation is a little bit confusing with numerous binaries. I don't mind having that many
binaries from s6 main package because the name of eachone is pretty clear. However, since execline
is a scripting language (shell alike)... why install all those helpers when using them in a script starting
with something like `!#/command/execlineb' makes sense and leave a little room for clarity?
I guess having those helpers in PATH could help simplify a few scripts to get rid of the header,
however it makes more sense to use execline script to do that and avoid adding too much
confusion to the user.
And to finish, I think adding OpenRC backends to be able to take advantage of process supervision
make sense. I will go for runit+OpenRC for now because I found runit-init design saner rather than
transmutations of PID 1 into unnecessary tasks, which should be left to others processes.
Remaining task(s): implement backends to OpenRC to be able to use process supervision from
other package (be it s6 or runit or daemontools) beside ssd (start-stop-daemon) would be surely
nice to have. Lets see what can be done.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
KuroNeko
n00b
Joined: 08 Oct 2014
Posts: 23
|
| Posted: Fri Dec 19, 2014 2:25 pm Post subject: Re: What does PID 1? |
|
|
Well, I'm not skargnet, but maybe I'll try to answer some questions from my own understanding of the matter.
| tclover wrote: | Very intersting dicussion to say the least.
@skarnet:
What does PID 1, let's call it init, for you? s6 seems promising and a bit cumbersome at the
same time.
First, what does PID 1? You raised multiple good reasons to make s6 interesting, but it
looks like it's not clear, for a user stand point, regarding what should PID 1 do. When I took a
look on s6, I was like... where's the binary that I should use as PID 1 to append to `init=...'
and what does that binary to begin with... I was rather confused.
Your response (at least what I've found): There's no clear response on what to append to `init=',
this is a implementation choice. It should handle stage 1 (boot) and stage 3 (shutdown/reboot) and
leave stage 2 to `s6-svscan'. So to the question what's PID 1: it's something, not entirely defined,
that should handle system initialization, system shutdown and service management.
I believe that this design is flawed because PID 1 should only be the parent of the entire processes
tree and leave system power up/down and service management to other PID(s). This is a saner
approach which ensure by _design_ that PID 1 will _never_ die. And this what runit-init does by
design and leave the task of managing services to another process.
|
If you start your computer, it will eventually execute the kernel and the kernel will eventually execute init. Because of that init is PID1 and has to set up the userspace. This is stage 1, and it is entirely your choice, if you want to do all initialisation tasks as PID1 or fork and let a child handle that for you.
You just have to be wary, that s6-svscan has some prerequisites before it can run. So PID1 has to wait for the child to do that, before it can execve into s6-scscan or it just does that itself and hands over, when it's done.
There is no do it all binary, that skargnet provides at the moment, but he said, he will provide one in s6-2.0, that he is currently rewriting to make installation in fhs paths easier and, as I said, to provide simple stage1 and stage3 scripts, to lessen some load on distributions or individuals, that want to pick s6 up.
He didn't provide one before, because stage 1 and stage 3 are entirely system specific. You either have to choose to do to much to cover every corner case or you don't cover every case and it won't work for everyone. Also, it won't be a binary, you'll want to be able to change your startup in the easiest way possible, and that's why we have scripting languages.
Also you don't need to run s6-svscan to run as PID1 in stage 2. You can let daemon reaping to sysvinit or upstart or whatever, but then it could die, without you noticing (although that s unlikely to happen) and all of them are bit bloated to do only the zombie killer but, don't you think?
I don't know, if you already read it, but all of that is expansively explained on skargnets website. It covers how to run s6, as PID1 or something else, rationale of design, stages of init and more.
http://www.skarnet.org/software/s6/s6-svscan-1.html
http://www.skarnet.org/software/s6/
| Quote: |
Second, s6 installation is a little bit confusing with numerous binaries. I don't mind having that many
binaries from s6 main package because the name of eachone is pretty clear. However, since execline
is a scripting language (shell alike)... why install all those helpers when using them in a script starting
with something like `!#/command/execlineb' makes sense and leave a little room for clarity?
I guess having those helpers in PATH could help simplify a few scripts to get rid of the header,
however it makes more sense to use execline script to do that and avoid adding too much
confusion to the user.
|
I think, I'm failing to understand, what you want to say here, but let me try anyways.
I think you don't have a problem with binaries, that do only one job, right?
But what do you want to say, that you don't want to install all of them?
If you don't need it, uninstall a helper, that should be no problem.
But execline is fundamentally different from the shell. An execline script is actually just a really long command, that is executed and uses the first few parts of the commandline. When it encounters the next program, it execs into it. Because that is not the expected behaviour of a normal program, you have to be sure, that your program, that you use in execline, supports this or use something like foreground. That's why they are distributed together.
Most of the programs in the s6 package serve the purpose to be used in runscripts, that s6 needs (and are usually written as execline scripts). They should help you, writing runscripts and and prepare the environment of your daemon.
There's a description over here: http://www.skarnet.org/software/s6/
| Quote: |
And to finish, I think adding OpenRC backends to be able to take advantage of process supervision
make sense. I will go for runit+OpenRC for now because I found runit-init design saner rather than
transmutations of PID 1 into unnecessary tasks, which should be left to others processes.
Remaining task(s): implement backends to OpenRC to be able to use process supervision from
other package (be it s6 or runit or daemontools) beside ssd (start-stop-daemon) would be surely
nice to have. Lets see what can be done. |
Well, some people are working on it (runit integration). skarnet is looking into making s6 integrate easier into init systems(how do you call that?) like OpenRC, although I think ./event is already rather nice. But it is actually not that easy to know, when your daemon is finished starting, if it doesn't fork or notifies you, as far as I understood. We'll see, if they find a solution.
Also I don't think, s6 does to much, it does as little it needs to, and it doesn't even handle startup and shutdown, so it is actually the user, that want's to stuff more into PID1, but I don't know.[/quote]
I hope this helps,
Neko |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Dec 21, 2014 3:49 pm Post subject: |
|
|
Hmm, nice to see some more reboot of djb's work; some of the utilities sound quite handy, though I don't really like the overall approach.
| Jonathan Pollard wrote: | | The target mechanism is similar to that of systemd (and, to a lesser extent, Solaris SMF's "milestones"). The procedures of enabling, disabling, starting, and stopping services are intentionally fairly similar to those of systemd, and the standard system targets are also intentionally similar to targets in systemd. |
seems like a waste of headspace to me.
The biggest issue I have with it though is its avoidance of shell; effectively doing the same thing as execline. I can't be dealing with such premature optimisation, nor can I be bothered to argue about it any more.
I also dislike the "directory-per-service" approach inherent in: "The service and supervise directories form two subdirectories of what is known as a service bundle, that also contains service interdependency, ordering, and installation information in other subdirectories."
"Service interdependences are expressed with ordinary symbolic links" sounds like gack to me.
| Quote: | | ..in fact I myself still feel sceptical about its use of C++, and will still stick to OpenRC in foreseeable future. |
Ah well that does seal it. No C++ in core initialisation, afaic. And yeah, OpenRC's approach is much better; it has none of the limitations I mentioned above.
Though it might be worth bringing C versions of some of the tools he mentions up to date, if the other projects he links haven't already. |
|
| Back to top |
|
|
skarnet
n00b
Joined: 01 Jul 2014
Posts: 25
Location: Paris, France
|
| Posted: Wed Dec 24, 2014 12:00 am Post subject: Re: What does PID 1? |
|
|
| tclover wrote: | First, what does PID 1? You raised multiple good reasons to make s6 interesting, but it
looks like it's not clear, for a user stand point, regarding what should PID 1 do. When I took a
look on s6, I was like... where's the binary that I should use as PID 1 to append to `init=...'
and what does that binary to begin with... I was rather confused.
(...)
Second, s6 installation is a little bit confusing with numerous binaries. |
Thanks for your feedback.
It confirms what I hold for certain now: lack of clarity and ease of use is what has been preventing s6 (as well as other supervision suites) from finding real success, because the entry barrier is too high.
Since this discussion began, I've been working on changing the build system of my packages to a well-known configure/make/make install system. This took me way further than I anticipated and I ended up rewriting a lot of code, but it is now done: s6-2.0.0.0 has been released yesterday. I encourage people who have been rebuked by the previous build system to give it a try now. (There's one important new feature: readiness notification support, as a prelude to dependency management.)
I'm now going to focus on clarity. s6 is confusing because it's a toolbox, providing a lot of mechanism but without any guidance or policy on what to do with it - tclover's testimony is not an isolated one. So, in 2015, I will try to lower the entry barrier by working on things like:
- A unique script suitable as /sbin/init for Linux systems.
- Policy suggestions to organize service directories and "stage 1.5" one-time initialization, with ready-to-run scripts if those suggestions are followed.
- Script generators to help people assemble the multiple tools the right way according to their needs.
As a specialist in a field, it's easy to get lost in advanced details and forget that tools should not require years of experience in the field to be used. I will try to improve on that front.
_________________
Laurent |
|
| Back to top |
|
|
shevy
n00b
Joined: 28 Aug 2017
Posts: 16
|
| Posted: Thu Oct 05, 2017 12:06 am Post subject: |
|
|
Old thread I came to heroically resurrect from the Fallen. However had, not so much on the
late some ~10 threads in discussion, but actually right what eccerr0r correctly stated:
- The problem ultimately is Red Hat.
Perhaps you can generalize, in the sense that it is not so much just "one" company or
corporation, but more the whole lot of them.
I have seen a transformation going on in Linux in general, and I think many others have
seen this too. The corporate devs often don't give a **** about other hobby devs.
You can see this in many projects; gnome being totally detached from the hobby devs
but I recently also saw this in KDE, where one guy explained why the superuser is
not allowed to use kate (!). All editors work just fine, but here you have a single dude
who wrote code to restrict what can be done. This is just one example of many more;
Ulrich Drepper "gimme cash before I fix a bug"; Poettering "I know better than to stick
to any standards"; Kay Sievers "I know better than the linux kernel developers in
how to write C code"; Anthony J in Mozilla "everyone loves pulseaudio so let's make
a hard dependency on it" and so on and so forth.
These corporate hackers (most of them are) usually have goals that are not 1:1 mapped
to what hobby developers. They cater towards the "mass of people". That is both good
and bad. Things get dumbed down and hopefully will be simpler for the end user - I
doubt this sort of but hey, it's what they claim. So at the same time, the more and more
people use linux, the more of them will have no interest in any hacking culture or getting
into things - as long as working on linux works for them.
From this context, systemd makes sense. You have indeed a unified interface to
resolve problems for people who can, ideally, copy/paste solutions that would work.
So if you are Red Hat, then yep - that's useful if you have a cluster system + things
such as puppet.
The problem is that, again, control is taken away from hobby developers. I remember I
had an infinite loop with systemd during boot. It did not start. I had no idea why. In the
old sysvinit days, the problem was shown right there. At worst I could google an
fix it. With systemd, the whole thing added unnecessary complexity and less resolving
power for me. (Note - I do not use systemd so it is irrelevant to me anyway; but I did
test it and it is both useless and pointless. All tasks that I have to do and that can be
automated, I automate via ruby scripts anyway, so I have no use case for systemd)
I think in the long run, if you don't want fat, greedy corporations destroying one linux
distribution after the other, you need to have some kind of ... well, "developer cohesion".
I do not really have any useful idea, unfortunately, because money pays developers
pays code. I just think that as long as corporations are in charge, this whole trend
of things getting worse rather than better, will continue. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Oct 08, 2017 12:00 pm Post subject: |
|
|
| depontius wrote: | So in the even simpler vein, it's really a matter of keeping sysvinit and letting it boot the system. Install s6, but not as the PID1 init daemon.
Don't bother with a forked OpenRC ebuild yet, just save aside start-stop-daemon, and substitute an edited version that uses s6.
At that point switching back and forth becomes as simple as swapping start-stop-daemon between the base and s6-enabled versions. (and rebooting) |
Yes, this is feasible.
As discussed before, ssd would just call on s6; if that means writing the final command-line to an s6-run script in a service directory, then fair enough.
(IOW: I withdraw my earlier objection, since it's been pointed out to me that having the actual command-line somewhere is useful; and it would enable what mv was talking about, as a side-effect.) | Quote: | | If it's really that simple, what are we waiting for, other than spare time? |
Motivation is another critical factor; besides programming, someone needs to drive the development from the admin-perspective.
Preferably several people, especially wrt bug-wrangling; but you need one curmudgeon to push when no-one else will, without demotivating your coders (a fine balance that few can manage, ime.)
It's a social activity ultimately, albeit at a remove. No users, no software. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Oct 24, 2017 11:48 am Post subject: |
|
|
| shevy wrote: | I just think that as long as corporations are in charge, this whole trend
of things getting worse rather than better, will continue. |
Agreed.
All of linux has started out from voluntary projects, run by people in their spare-time for free.
Including the GNU projects that birthed it.
Most of the interesting stuff is still maintained by volunteers, or at minimum reliant upon the unpaid work of many volunteers and first-line users.
No real answer; just wondering whether the community can ever simply be removed from the equation.
Clearly it cannot, so the strategy instead is to coopt our work, while keeping up a barrage of anti-social media and marketing campaigns, to convince us that we're getting "awesome sauce" for FREE; so just shut up, put on a corporate t-shirt, and sing along, while ofc providing unpaid labour (toward the goal of coopting our craft, and selling it back to us with much less utility, locked-down for client vendors to sell us product-placement^W "content".)
Seems the corporations need us, more than we need them. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Tue Oct 24, 2017 5:39 pm Post subject: |
|
|
| steveL wrote: | | Most of the interesting stuff is still maintained by volunteers, or at minimum reliant upon the unpaid work of many volunteers and first-line users. |
| steveL wrote: | | Seems the corporations need us, more than we need them. |
Is that really true? I'm not sure what you're referring to by "interesting stuff." But consider this, the Linux Foundation is a "business league" (1). It seems like kernel development has favored business needs. That isn't inherently bad, but it doesn't necessarily address the needs of non-business interests.
1. https://en.wikipedia.org/wiki/501(c)#501.28c.29.286.29
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Tue Oct 24, 2017 11:07 pm Post subject: |
|
|
| steveL wrote: | No real answer; just wondering whether the community can ever simply be removed from the equation.
Clearly it cannot, so the strategy instead is to coopt our work, while keeping up a barrage of anti-social media and marketing campaigns, to convince us that we're getting "awesome sauce" for FREE; so just shut up, put on a corporate t-shirt, and sing along, while ofc providing unpaid labour (toward the goal of coopting our craft, and selling it back to us with much less utility, locked-down for client vendors to sell us product-placement^W "content".)
Seems the corporations need us, more than we need them. |
This may sum up the current state of things as well as anything I've read. The manner in which you and I (and many here) have avoided all or most of the corporate pollution of Linux by using Gentoo is a testament to that.
| pjp wrote: | | Is that really true? I'm not sure what you're referring to by "interesting stuff." But consider this, the Linux Foundation is a "business league" (1). It seems like kernel development has favored business needs. That isn't inherently bad, but it doesn't necessarily address the needs of non-business interests. |
Even if that's the case, all I know is that I've yet to detect anything in terms of the kernel preventing me from doing what I want with my system, while most of the userland shit (especially the desktop and effectively anything with 1000 light years of freedesktop.org) seems to do nothing but.
Tom |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Wed Oct 25, 2017 6:43 am Post subject: |
|
|
| tld wrote: | | I've yet to detect anything in terms of the kernel preventing me from doing what I want with my system, while most of the userland shit (especially the desktop and effectively anything with 1000 light years of freedesktop.org) seems to do nothing but. |
+1
Traditionally the corporation owns the software and the users are the product. That's disgusting, but most people have learned how to deal with being farmed in that way. With RedHat, both the user and the software they want to use are treated like an intrusion in the labyrinth they built through the middle of said user's home, and the product is the guided tours they sell. If you buy into their world, not only do you no longer know how your own system works... neither do they. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Wed Oct 25, 2017 1:55 pm Post subject: |
|
|
| tld wrote: | | Even if that's the case, all I know is that I've yet to detect anything in terms of the kernel preventing me from doing what I want with my system, while most of the userland shit (especially the desktop and effectively anything with 1000 light years of freedesktop.org) seems to do nothing but. |
Well, SteveL commented on corporations needing "us" more than "we" need them. I'm not sure either case is true. The "interesting" stuff I see is done by corporations. The core offerings may be open, but he glue (aka, GUI and usability layer) are proprietary or only available with paid support. And, yes, in most cases, those offerings are probably only really useful to businesses, but that is still a barrier to entry for a professional wanting to use them for resume / interview familiarity.
Comparing userland with the kernel as far as user impact is concerned seems a bit one-sided. By its nature, the kernel should mostly be invisible to the user whereas the desktop isn't. Since it is on topic, I'll mention it, but systemd is the only significant annoyance I've experienced. Which is driven by RedHat.
| Ant P. wrote: | | With RedHat, both the user and the software they want to use are treated like an intrusion in the labyrinth they built through the middle of said user's home, and the product is the guided tours they sell. If you buy into their world, not only do you no longer know how your own system works... neither do they. |
Exactly. RedHat is still pretty much the Linux OS. Were Red Hat goes, so do the prevailing winds. Corporations will either pay for the industry standard and accept it for what it is, or they have the need / staff to go against the current. Which leaves users in the tiny area off to the side who get the same choices, with different impact.
Also consider that most of the cloud is not open, but is built upon open software.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Oct 26, 2017 11:29 am Post subject: |
|
|
| pjp wrote: | | Well, SteveL commented on corporations needing "us" more than "we" need them. I'm not sure either case is true. The "interesting" stuff I see is done by corporations. The core offerings may be open, but he glue (aka, GUI and usability layer) are proprietary or only available with paid support. And, yes, in most cases, those offerings are probably only really useful to businesses, but that is still a barrier to entry for a professional wanting to use them for resume / interview familiarity. |
Wow.
I really think you need to re-read your paragraph quoted above.
From where I'm sittting, a) it's a load of nonsense, and b) you seem to have no insight into the idea of FLOSS software.
| Quote: | | Also consider that most of the cloud is not open, but is built upon open software. |
Sheesh.
You mean it's all built upon FLOSS.
Oh wait, some numpty at a corporation wrote a crappy script, so we all need them much more than they need us. /s |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Thu Oct 26, 2017 1:50 pm Post subject: |
|
|
Thanks for your time.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
