The fear isn't strictly "oh god i have to install 500 servers to make systemd work" the fear is that systemd will drop NSS support in favor of their own kdbus communication protocol that won't be supported by any non-systemd-aware application hoping to get an answer from gethostname().
That wouldn't just wreak havoc to non systemd-aware applications that would break the system. The systemd guys are not gonna break a POSIX call !
You can't buffer your way out of duplex mismatches. And basics, like the L2 issues (including ARP) cover why you want everything set to auto/auto, or fixed/fixed.
With modern gigabit switches why would you meddle with manual duplex settings anyway. I haven't had to deal with these issues for some time now and have forgotten almost everything about it. The only thing which I do still remember is that ICMP isn't to be relied upon when troubleshooting these issues.
But this goes back to the job recruiter wanting an Allround "specialist". Which is contradictionary. Either you have someone with broad knowledge or a specialist. Hopefully you have a specialist with a passion who is willing to acquire broad skills on a ad-hoc basis. But you will not know this unless you let them try out.
That you will get a lot of people who oversell their skillset is a symptom of the bombastic job descriptions of today. I don't dare to apply for a job these days, I feel completely unqualified and unaccomplished. This in contrast to a big part of the market which just bombards recruiters with sollicitations and hope that something sticks.
No you don't get it. The fact that this is false is precisely the problem that Debian faces. Many applications need process management functionality. Under initd that's implemented on a per application basis as a one-off adhoc function. That's what is disappearing. The developers are no longer going to be created or maintaining that code. Which means that Debian if they don't default to systemd will have to write and maintain huge chunks of upstream code. That is port. Debian has always allowed people who want to port to port. But they themselves have never before been asked to take on a major porting project. That's what the anti-systemd people are demanding, a major porting project. Not necessarily by 2014 but very soon thereafter. Many think one that is simply going to be impossibly big during the lifespan of Jessie.
This is what you hope and this is YOUR vision of the future. All the process management consolidated in systemd. And you're forcing us all to go with it.
Making it the default in Debian won't matter. For example embedded distributions even 10, 15 years from now may still be using initd or OpenRC or some much lighterway init system. There are possibly a group of admins who want simpler systems though and they can work off of those. Linux already has a diverse group of distributions it has that culture. That's not division. There will be some non-systemd ones, most likely some will be child distributions of Debian. It is not going to be hard to just drop most newer software and maintain a traditionalist distribution.
Who wants to maintain a traditionalist distribution with ancient software. That's exactly why systemd is dividing ! If you want modern software you will have to take the complex modern plumbing with it.
The Linux kernel continues to improve and add new functionality yet you run it.
Choosing the anticipatory scheduler doesn't force you to suddenly use TWM !
Meaning, there is an expectation of being aware of problems that can occur - by accident or stupidity (3rd party or yours) - with any non-trivial setup, including troubleshooting network problems that causes Apache to proxy among several PHP boxes (if you distribute horizontally) or why or database connections get truncated/closed prematurely (damned unknown firewall) or why your system is so slow (until you fire up snoop or something like that and you detect a shit-ton of re-transmitted packages because the NIC on your database server is running full duplex while the NIC on your PHP box is running half-duplex).
a) Should Debian fork I.E. should a child distribution of Debian be created which is designed to support initd. I haven't heard anyone object to that. It is a weird sort of threat since the systemd people are in favor of it. That's a fine escalation. IMHO the vast majority of the anti-systemd people are system admins not developers so they don't have the right technical skills to pull off what they want long term but I see no harm and lots of benefit in them creating the bridge software over the next few years to keep this alive.
Wow that's very ad hominem. Who are the ones that need to grok the init system ? Yes the sysadmins not the developers unless they develop systemd.
Debian, a stable community distribution should have forked debian to test systemd. Instead of the other way around. It's OK for the corporate distributions who have big stakes in systemd (proper service harnassing, paid developers, etc...) to incorporate it early on. But please don't take this big dividing stance in a community distribution by makiing it the default until systemd has proven itself and the sysadmins have had time to catch up. It's still in its baby phase growing all sort of organs and appendices (dhcp server, ntp daemon, eating udev,...), let the feature creep first dissipate.
The only way that we have found for being able to assess a candidate's suitability for work at our company is to write tests that suit the job, and then ask the candidates to demonstrate their skills. We've had people with all sorts of qualifications relevant to the LAMP architecture not know the basics of regex, sql, bash, etc. Let alone what ARP is.
ARP as in ethernet ip-mac mapping ? How exactly is that relevant to a LAMP job ?
Slackware makes an awesome desktop. With FreeBSD you'll have to
compile KDE from ports (make config galore) or use the precompiled but broken version (old Xorg) on the media.
Exactly, but what I would like to know is what are the critical SMART values to watch for in SSD's ? Any results on that yet, should we expect them or will
they vary even more by manufacturer/model making a "top 5" list impossible.
I'm a government worker. I have 8 bosses (actually probably more, but who cares). None of them manage me at all.
Only 8, I work at a university in a niche engineering department. We have +12 professors. 12 Kings who only care about their "research" and prestigeprojects.
If Microsoft maintains an app-repo they will scrutinise it otherwise there is no point in using it. Yes there will be
attempts to subvert it and get malicious software in there. Just like with the Apple App Store. And sometimes they will succeed but overall this is a brave move of them. Just like their new implemention of Virtual Desktops. I applaud it.
That's not true Slackware uses SysV init (sysvinit-2.88dsf-x86_64-3).
Its init scripts are more BSD like. A few global init scripts in/etc/rc.d/ instead of specially named and numbered symlinks in/etc/rcX.d/.
I'm not talking about samba the daemon, I'm talking about the system mount utility
and the fact that you can't mount an old smb share anymore (win98/samba 2.x).
SMB support is there it is fully integrated as a filesystem. smb://ServerName/ShareName in finder and you connect. ipfw to PF was an upgrade stateless to stateful.
That's not what I said or meant to say. They removed support for windows 95/98 style servers (samba 2.x) In Lion you could still use it by toggling a sysctl setting http://support.apple.com/kb/HT... That was removed completely in Mountain Lion.
Ipfw is a stateful packet filter (https://www.freebsd.org/doc/handbook/firewalls-ipfw.html). But yes I should just get acquainted with pf.
ipfw's been gone for a while... but they've made a lot of other stupid choices that might be good for general users, but make things a pain when you're administering lots of machines.
Ipfw was deprecated but not removed. I found it much easier to setup for fail2ban than
pf. Pf is more complex than just simple rule based filtering firewalls (iptables,ipfw,...).
The only good news is that they *finally* updated the mini... which means we'll finally be getting new hardware to replace our xserves. (the cancelation of which should've been the clue that they didn't care about 'enterprise' type stuff anymore). I'm thinking of putting FreeBSD or similar on 'em though, rather than MacOSX.
If you're gonna switch to FreeBSD anyway why not just a generic 19" x86 server ?
What really bothers me though is the removal of old SMB support (I don't know if it was Mavericks or ML) and now
the removal of the ipfw firewall. I had just gotten around to learning that and setting up a Launchctl plist.
The fact that the green button now fullscreens an application is another change I don't like.
Slashdot Mirror
That wouldn't just wreak havoc to non systemd-aware applications that would break the system.
The systemd guys are not gonna break a POSIX call !
With modern gigabit switches why would you meddle with manual duplex settings anyway. I haven't had to
deal with these issues for some time now and have forgotten almost everything about it.
The only thing which I do still remember is that ICMP isn't to be relied upon when troubleshooting these issues.
But this goes back to the job recruiter wanting an Allround "specialist". Which is contradictionary.
Either you have someone with broad knowledge or a specialist.
Hopefully you have a specialist with a passion who is willing to acquire broad skills on a ad-hoc basis.
But you will not know this unless you let them try out.
That you will get a lot of people who oversell their skillset is a symptom of the bombastic job descriptions of today.
I don't dare to apply for a job these days, I feel completely unqualified and unaccomplished.
This in contrast to a big part of the market which just bombards recruiters with sollicitations and hope that something sticks.
This is what you hope and this is YOUR vision of the future. All the process management consolidated in systemd.
And you're forcing us all to go with it.
Who wants to maintain a traditionalist distribution with ancient software. That's exactly why systemd is dividing !
If you want modern software you will have to take the complex modern plumbing with it.
Choosing the anticipatory scheduler doesn't force you to suddenly use TWM !
Shouldn't the switch rectify that by buffering ?
Wow that's very ad hominem.
...) to incorporate it early on. ...), let the feature creep first dissipate.
Who are the ones that need to grok the init system ? Yes the sysadmins
not the developers unless they develop systemd.
Debian, a stable community distribution should have forked debian to test systemd. Instead of the other way around.
It's OK for the corporate distributions who have big stakes in systemd (proper service harnassing, paid developers, etc
But please don't take this big dividing stance in a community distribution by makiing it the default until systemd has proven itself and the sysadmins have had time to catch up.
It's still in its baby phase growing all sort of organs and appendices (dhcp server, ntp daemon, eating udev,
ARP as in ethernet ip-mac mapping ? How exactly is that relevant to a LAMP job ?
More like Windows Vista -> Windows 8.1. FreeBSD 7.x wasn't that long ago.
Slackware makes an awesome desktop. With FreeBSD you'll have to
compile KDE from ports (make config galore) or use the precompiled but
broken version (old Xorg) on the media.
Exactly, but what I would like to know is what are the critical SMART values to watch for in SSD's ?
Any results on that yet, should we expect them or will they vary even more by manufacturer/model making a "top 5"
list impossible.
You're absolutely right, But it's been this way for 5 years and in academia this client/employer distinction is
especially blurry.
Huh what about 196 Reallocated_Event_Count. Nothing we didn't know already but is there any data out
for SSD's, that's what I would like to know.
Just keep your Raid arrays small in number of drives if you use Desktop drives and/or
spring the extra money to buy WD Red's which do have TLER IIRC.
So you overwrite your drive with 0 (/dev/zero) and 1's (/dev/one???) but still you were able to e2fsck it afterwards ?
Only 8, I work at a university in a niche engineering department.
We have +12 professors. 12 Kings who only care about their "research" and prestigeprojects.
Doesn't that imply that you have a process of befriending people in interesting companies or that your choice of companies isn't that big.
If it knows how to wrap the different installers' (nullsoft,installshield,etc...) /silent options, then it's fine by me.
If Microsoft maintains an app-repo they will scrutinise it otherwise there is no point in using it. Yes there will be
attempts to subvert it and get malicious software in there. Just like with the Apple App Store.
And sometimes they will succeed but overall this is a brave move of them.
Just like their new implemention of Virtual Desktops. I applaud it.
Is this technology supposed to replace Windows Installer and MSI packages or does it built on it ?
That's not true Slackware uses SysV init (sysvinit-2.88dsf-x86_64-3). /etc/rc.d/ /etc/rcX.d/.
Its init scripts are more BSD like. A few global init scripts in
instead of specially named and numbered symlinks in
I'm not talking about samba the daemon, I'm talking about the system mount utility
and the fact that you can't mount an old smb share anymore (win98/samba 2.x).
Yes but does the samba3 port include a mount utility ?
That's not what I said or meant to say. They removed support for windows 95/98 style servers (samba 2.x)
In Lion you could still use it by toggling a sysctl setting http://support.apple.com/kb/HT...
That was removed completely in Mountain Lion.
Ipfw is a stateful packet filter (https://www.freebsd.org/doc/handbook/firewalls-ipfw.html). But yes I should just get acquainted with pf.
Ipfw was deprecated but not removed. I found it much easier to setup for fail2ban than ...).
pf. Pf is more complex than just simple rule based filtering firewalls (iptables,ipfw,
If you're gonna switch to FreeBSD anyway why not just a generic 19" x86 server ?
What really bothers me though is the removal of old SMB support (I don't know if it was Mavericks or ML) and now
the removal of the ipfw firewall. I had just gotten around to learning that and setting up a Launchctl plist.
The fact that the green button now fullscreens an application is another change I don't like.
Are you talking about FreeBSD ? I was able to crash it with a swapfile by writing to the swapfile after
swapoff but while it was still a memory disk.