Dude seriously WTF? I'm serious...WTF are you doing man? those "utilities" are about as useful as tits on a boar hog, worse because at least the tits ain't slowing down the boar!
Yeah they do suck, but some of them control things like the Wireless hotkey which the clients do expect to work.
And yes Ninite is fantastic, I've been using it for 3 years now myself. Will check out driver-booster. Thanks !
BS as I've used WinXP drivers in Windows 7 and Windows 8 drivers in 7 as well, that's the nice thing about Windows they don't crap on drivers all the time. In fact the only caveat is that if you are using 32bit XP drivers you have to use Win 7 32bit but Linux AFAIK won't let you mix 32bit and 64bit drivers either so no difference there.
I thought the new improved driver model of Windows Vista and up made Windows XP drivers necessarily incompatible ?
Maybe it works now but I tried that back when Windows 7 was new and that never worked.
I had to downgrade a new Toshiba laptop last week and some toshiba utilities/drivers wouldn't run on Windows 7 or didn't exist at all.
And I'm not gonna put a Preview release on a client's worklaptop even though it usually is pretty stable, that's just silly.
Quit repeating BS that was last true under Windows 98. Windows 2000 was rock solid over a decade ago and infections since Windows 7 came out over 5 years ago are mostly down to user stupidity than the operating system, see the number of Android device infections. Even my mom, who can't program a VCR, would see your bullshiat.
Malware has changed but it's not dead.
Nowadays it's browser addons like toolbars and their virulent reinstall utilities that get into the systems.
Antivirus programs are still playing catch-up to this threat because for long they
didn't consider these advertising, browser hijacking programs to be malware.
Nowadays they have created an entire new category for this crapware (Potentially Unwanted Programs) but
mostly you still need to opt-in most AVG software to clean this garbage.
bIsWindowsXPorLater = (osvi.dwMajorVersion >= 5 && osvi.dwMajorVersion >= 1);
bIsWindowsXPorLater = (osvi.dwMajorVersion >= 5 && osvi.dwMinorVersion >= 1);
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).
Shouldn't the switch rectify that by buffering ?
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
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,
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 ?
With your bare hands?!?
