We had a client come to us recently and say, "we bought this tool we need to use, but we don't know PowerShell and it needs PS to actually do anything useful".
Me, being the Linux admin, had it land in my lap. Wonderful. I can hack a bit of perl or bash, and some rudimentary C, C#, or C++ or what have you, but I'm not really a programmer. I dislike doing it, but did it anyway. The customer got what they wanted (they were very pleased) and I learned another language in the process.
At no point in this process was there an opportunity to say "I'll use another toolkit". I thought about it, looked a bit, and determined there was nothing that would actually do what the client wanted, short of what they'd actually specified (especially since the project spec said "use this").
The rise of tablets really isn't going to disrupt things as much as columnists like to claim.
Sure it will - just not in the same fashions they think it will. They're too fascinated with the things when, in reality, they're little different than a small laptop or similar, sans a keyboard. The WinCE and similar devices of yesteryear had proportional levels of utility to a desktop 10 years ago - arguably, even in terms of cost. People didn't jump ship then, either: they sucked compared to a full desktop for 90% of what a person might do with computers.
People will just be using less of the following than than previously (instead of 'less PC'): * Reading traditional print media * Watching "TV" * IM'ing * Casual browsing, maybe. * Finding a PC to look up something quickly * Console gaming (consoles have already replaced PCs where they are able to do so in this regard)
Yes, these trends are already in motion to a large degree, but they'll accelerate.
Quite possibly, it means the End of Apple. Apple has not existed in a profitable, quality form under anyone except Jobs; he is the man with the vision.
Without Jobs, Apple is likely to de-orbit, barring a miracle. The company has been driven by him for so long, there is little the company does which is not his Image.
Take him away, and Apple products are likely to become like most other consumer toys: generic. Apple was to the 2000s like Nike/Reebok and Sony were to the 80s/early 90s: an image accessory that everyone simply must have.
No, it's not over yet, but assuming Jobs is actually the one behind the current Apple incarnation, it will be soon.
We shoot and otherwise execute bad human beings every day.
I don't see what sympathy someone's mortal husk should be regarded simply because they're "human".
Likely: the man is dying. He won't be back.
My sympathies to his children, though. They'll likely have a lot of issues to work through given his absence and disregard for their well-being; that kind of thing tends to leave scars. (Jobs is/was an absentee parent, going so far as to deny paternity of at least one of his children.)
Re:What functionality are we BSD users ...
on
Xfce 4.8 Released
·
· Score: 0
BSD users? I thought you liked moving bits around with bar magnets or some such thing?
That said, I imagine you'll not miss much more than you already are. Despite the whole marathon that the various BSD 'package management' systems provide you with, one thing the BSDs typically have going for them that Linux does not is well-designed interfaces. (They may not be usable, and they may not be documented, but they are well designed.)
Re:Making it just as heavy as Gnome and KDE now?
on
Xfce 4.8 Released
·
· Score: 3, Informative
The irony is that all these subsystems worked pretty damn well in QT3 years ago, and they've only gotten better, since. A lot of the long-running bugs in the various GTK wm subsystems were never really a problem for KDE, and things like the VFS implementations worked much, much better.
You really need to break their will - to use the GUI. It's not terribly useful for people who will be using Linux as a server or development platform. They don't need a course to tell them these basic, largely intuitive things.
They need to start from the core of the system; ie, what the system does as it boots.
Walk them through that. Have them read over and analyze the output from dmesg, for starters.
Then start them with some basic console commands. ls, du, who, ps, top, mv, cp, ln, rm, kill, ed/vi/nano, find, whereis/where/which, less/more/cat, and echo are useful, but also be sure to let them know how to find help, and where to look for things - man, apropos, info,, etc. Be sure to include the process of how to use these commands adeptly: man and apropos will go a long, long, long way.
I can't emphasize the use of apropos and man enough. Teach them how to use these things - ie, "how to help yourself" and they will be competent Linux users able to adapt to a myriad of other systems as well (with time).
Touching on hardware interface commands (lspci, lsusb, etc.), system proc files (/proc), exit codes, lsof, and other "programmer useful" things would be nice, too. Package management (dependencies, managers, frontends, interfaces, etc.) would likewise be useful.
Once they understand the kernel boot process, the basics of shell operation, and the system boot process (init/upstart/rc/whatever), they should be well on their way to competence. (Then, of course, there are the usual 'gotchas' everyone runs into in their course of growth - the accidental rm -rf, or killall on a non-Linux system, for instance.)
I would verge towards overloading them with work to encourage them to dig in, instead of going too lean. If you must, grade on a curve - there's a lot to learn here if you're not a competent "professional" already, and a lot of stuff to "unlearn", if coming from the Windows side of things (eg. "errors").
I'm not sure who you're replying to (slashdot's threading kinda sucks at times), but I thought I'd note that pretty much anything "Linux" on FreeBSD usually requires non-trivial Linux binaries to work - usually it's a compatibility package from ports that has the actual binary packages from (say) CentOS and a FreeBSD kernel shim.
I know that their are lots of security issues with the Nvidia proprietary driver supposedly, but I have a sneaky feeling this is because more of the open source community look for a stick to beat nvidia with to try and encourage them to open source their driver. I also think that purely theoretical security issues that only give root to a normal user are not such an issue on single user desktops that are the most likely machines to need graphics acceleration (Personally I disable X on servers).
I've not looked into them, but I would suspect that the security issues with nvidia drivers may be attributable to method in which X implements getting pixels to your screen (client/server).
Girls have boyfriends. They also have female friends. They are not solely keeping these pictures on their hard drives and cameras for personal use (more than likely).
Funny thing about pictures on the Internet: they're trivially copied. Boyfriend copies the picture to his friends (or just one friend), or posts it to a forum: the picture is out, and will live forever on hundreds of 'porn agregators' (lacking a better term), presuming the girl isn't a skag. Likewise, girls are/can be catty: what's stopping them from spreading the nude pictures in a bitter attempt at becoming more popular themselves (thinking it would ridicule the origin)? We're talking about virally social teens, here, not top secret data on government networks: there's literally a thousand and one ways for such pictures to spread to the Internet At Large.
So, in short: it's entirely possible that hundreds of thousands of men and women have viewed, downloaded, etc. child porn and not even be aware of the fact that it is child porn, simply on the basis of "some women look like children and some girls look like women". I recall a couple girls in high school who looked significantly older than 16-18 - and no, I'm not just talking about curves (though that applies too).
It's just like "honest, I thought she was 18, officer!" scenario, except the evidence never disappears and the so-called 'victim' can never grant consent. I would not be surprised if there is legal child porn floating about the internet right now, on "valid" sites which the US federal law enforcement agencies knows about, but allow to exist -so that they can use it as an added charge for someone down the line, if they ned something to vilify them further/want to make sure the charges stick.
I didn't compare Lustre to LVM/RAID - I compared ZFS to it.
What sits on either would be Lustre, obviously. ZFS is significantly superior to RAID + LVM in pretty much every way, barring super-expensive hardware RAID controllers where RAID has a slight trump in and of itself. (Though it should be noted that these RAID controllers would likely provide significant benefit to a ZFS system, too.)
What I have to wonder is: what kind of storage methods or devices does a 'network cluster file system' use? Here's a guess: local storage. Since ZFS is already geared to be a 'network aware' filesystem, in many ways (as much as a filesystem can be, I suppose), it's got fundamental underpinnings (like get/send and the ability to use pools and zvols on other physical hosts transparently) which make it much, much better for clear pictures of your data than ext# on LVM or straight RAID.
To be frank, ext# has more in common with FAT16 than it does ZFS filesystem level functionality (nevermind the fact that ZFS is filesystem, volume manager, and storage controller all in one, doing things which "just a filesystem" could never accomplish on its own).
Yes, because that was obviously what I intended to convey. Thank you for pointing out that your level of reading comprehension is likely very similar to that of a politicians'.
Managing filesystems in lvm2, on raid cards - all with their own specific commands - is a real pain in the ass when you've got tens of hosts or more per admin, with many different roles and functionality.
So then you've got to have snmp set up for each of those hosts (often with different controller cards) to monitor those RAID cards status (with the shitty RAID console tool which lacks anything resembling documentation). Then you've got to manage LVM, with its "easily" understood UUIDs. And then you've got to manage your filesystem - whatever that may be - to verify it's intact.
With Lustre, you'll be adding another layer of 'shit I have to monitor'. Even if your hardware is 100% identical across all nodes, is that not a significant pain in the ass to manage for?
ZFS just needs an HBA and 'bare' drives. Baring ZFS itself failing on you (not outside the bounds of reason), you've really only got one/two things to look out for with zfs: data errors and disk failures, both of which are reported with zpool status and can be easily monitored. This is regardless of the version of the system, or even which OS it's running on (Solaris and its derivatives, FreeBSD, and yes, even Linux).
Unlike with RAID, I don't have to contend with the possibility of RAID-5 write hole.
If I need to move to new hardware in a pinch, I can - trivially. I can be a desktop, assuming I've got a suitable controller for all the disks (nothing 'special').
Rebuilds are a fraction of the time as they are on hardware RAID (or mdraid, until recently), because only the actual data is replicated.
Hell, you're going to get more performance out of ZFS than you will from the 'common' vendor (Dell, HP, IBM) RAID cards.
I'm assuming Lustre will scale better on ZFS better than on traditional methods because everything else scales better on ZFS. Growth is easier; management is easier; maintenance is easier. "Storage management" is actually somewhat enjoyable with ZFS, instead of the tedious skulduggery it usually tends to be otherwise.
It does? How do you figure that? You will be somewhat limited compared to other filesystems for 'raw speed', but that's why ZFS has build in read and write cache functionality (via SSD or ramdisk). Unless we're talking about massive amounts of sustained reads and writes, with no time for the disks to catch up, I suspect that (oh) 32Gb of SSD or so would do the trick for most hosts, or 128Gb for a 'high demand' host member to Lustre.
So yeah, if you consider cache, ZFS is going to blow the snot out of anything without it. It would be trivial to configure a zvol to offer total IOPS capability which would saturate the bus bandwidth with small writes, for instance.
If you're archiving, just don't use cache drives.
Besides, I'm reasonably certain that Lustre actually would prefer ZFS as a backend (in terms of performance) because that's what they're using. You can't scale to petabytes of storage with those other filesystems, if for no other reason because they lack the built-in parity and suffer a number of other 'lots of disks' management issues.
Seriously: for the price of storage today, adding an SSD in front of a couple disks to make the performance markedly better is not a significant cost. It's an easy out, and is far cheaper and easier than pretty much any other high-IOPS approach.
You're kinda funny, but there's something your underestimating (or do not simply fully comprehend) about IT.
IT projects scale exponentially in complexity. It might be a 'simple' x units of y, j units of k, a units of b - all tied together with such-and-such technology to distribute whatever on someone else's fabric - in your mind, but a couple things inevitably come up:
* problems exist in wide, homogeneous environments which would never, ever occur on any one of the devices within its production lifetime. Weird shit happens. * Little compatibility issues ultimately culminate into lack of functionality as your deployment grows. * There is no "just" - there will always be more end-user support. (Do you really think it'd just be 'seamless' for people to use some quick app on an iPad to view this stuff?)
Most importantly (and the same problem this fucking gov't contractor project had):
* "What now" - the systems may be perfect, but if it doesn't actually improve the real-world application by a significant amount in proportion to the time and effort required to actually use it, it's a worthless product. Most 'complex' IT systems sold by vendors and/or contractors are crap: they take forever to tool up on, and by the time the people/organization is competent with the application (untold hours invested on training and familiarization) it's time to upgrade, replace it, or what have you. Being the government, I'd expect a Microsoft style release schedule - about 3-5 years and maybe 3-5 releases before they actually come across something which the majority of the people would consider 'usable', followed by some regressions and ultimately EOL'ing the product to start over from scratch.
Border security is not a problem that you should look to 'fix' with IT. It can surely be sped up with IT, but in the same way that grunts-on-the-ground have their performance/efficiency improved with IT: communication, survivability, and awareness. Basically, BP needs the same tools the cops have already, as well as many the military has, to do their jobs effectively.
How can anyone claiming to be 'intellectual' in any fashion treat astrological bullshit with anything more serious than disdain? You might as well hold Magic: The Gathering as your religion...
There's an easy-to-implement solution (or four) for this problem which have been tried and done successfully throughout history (assuming the idea is to keep foreign invaders out and/or encourage illegal and likely disloyal foreign nationals already in your country to leave):
* An armed wall with bastions. I suspect the cost would be comparable if you were to have a sane human/machine monitor ratio (hint: monitoring does nothing if there is no physical deterrent worth being concerned about) * No social sympathy (legally and culturally) for the 'condition'. Allowing the motivated ones to come here only dillutes their own home country's strength of survival. Real, actual efforts to prevent them from working here. * Go in and shoot the bastards who are ruining the fun in their home country, and take it over as a corporate holding stock, of sorts (hey, the US gets accused of much worse, every time a Republican is in office). * Allow the people in those border states to legally defend themselves. The bandits who break in, steal, etc. along the border (who are often called 'immigrants') are often treated by LE as victims, whereas the property owners are acted upon harshly if they do anything to protect their livelihood.
At a functional level, Lustre (GPL) is to ZFS (CDDL) as CXFS (commercial) is to XFS (GPL) for SGI. They are the upper 'cluster' layer to take advantage of the underlying filesystems' capability. I believe this approach is divergent from that of GFS, due to the upper/lower approach, but I'm not that familiar with clustered filesystems.
However: Arguably, Lustre on ZFS is a mumuchch better option due to ZFSs inherent capability superiorty over XFS. I've liked XFS historically, but ZFS is so drastically superior than anything else out there (in terms of storage management and available capacity and throughput) - all 'out of the box' that it's a no-brainer to use zvols for things other than direct zfs posix access. (For instance, they make great VM iSCSI targets, or local raw disks for VMs, or..)
Side note: the linux zfsonlinux.org port is being successfully used as the base volume manager for Lustre right now, so it is apparently quite capable/stable at that level. (zfsonlinux does not yet have zfs posix support.) Lustre on ZFS It, apparently, scales much better than the traditional LVM/RAID/etc. backend methods.
Where else can you get 6-8 years of rock solid job security at a well paying job with reasonable hours? This is a cost of entry.
No, no it is not. Not unless you get a contract saying so, and the company actually remains solvent.
You fail to realize the potential cost of such hours for employees to the company. Knowledge workers working that much, making bad decisions due to exhaustion or being burnt out (or not really working at all) is a huge, huge risk. Most people can't do it for 5-8 hours a day; even fewer can do it for 10, and almost nobody can do it for 12 and still function optimally (nevermind have a life outside of work, unless drinking themselves to sleep counts).
There are many, many companies which have done this before - see the "dot com boom". You are making a huge bet that the company remains solvent, and that if cutbacks are made, you will not be on that list. So things are going well, but not profitable: how long can the company keep things going at the current rate? If what you've got is working and is tenable, it is a huge risk to change the equation by adding another stressor. You'd be better off to short-fund things and go into the red, then borrow to get where you're going than to sell your non-fungible resources (your employees) short (by short changing them personal time).
Even men at war, fighting for their very lives, have required downtime.
I was essentially 'unemployed' for the better part of three years before finding employment in December 2009. I've got a family, and unemployment isn't going to handle that. I worked pretty much every job imaginable - contracting, construction, misc. physical labor, etc.
Now, I'm salaried at below market rates (even for IT in this low-income area) and working 45-60 hour weeks. I have to occasionally drive around town to client sites and do not get compensated for my mileage above/beyond my time, and the on-site work I do does not negate my routine obligations (as part of my position).
Guess which one I prefer?
I'll give you a hint: my child never went hungry while I was unemployed, and I only begrudgingly collected from the state (if only because I put in years of unemployment insurance to the state, yet was 'ineligible' for some cockamamie reason). Heat and electricity never went off during the winter. Sure, there were days when I rued
But in general, I was happier and less stressed then than I am now: I could sleep in. Any deadline was my own to set, and telling a client to fuck off because they were being offensive or degrading was no big deal. They were, after all, my client, and little was lost aside from a days' work. I was able to be more honest and forward due to not having "my position" on the line: I was my own man, my word was my bond, and my act
No, I probably didn't work much more than 3-4 hours a day, on average (not counting time spent looking for work). We got by.
There is nothing to be gained from overworking yourself. If things come to that ("50 hours or the highway"), it's better for you, as a person, to grab your rifle and head for the woods to find yourself some meat.
Some people like those 10 hour days. If I were single, I'd probably be just fine with that - but I'm not, and doing little things like cleaning up after kids, putting them to bed, and helping with dinner take time. Relationships take time. I'd rather grow old and poor with someone, with children growing into adults, than alone and "getting by" with a few dozen luxuries I've 'managed' on my meager wage.
Let me start off by saying: a universal 50-hour work week, for an IT type position, is stupid beyond belief. Your manager/owner is an idiot for even suggesting such a thing, and apparently does not understand others all that well.
Most people do not thrive on such hours; they flounder and fail. It doesn't matter if it's manual labor, doldrum sales work, or polishing the brass on the Titanic (which this sounds oddly similar to). IT work, specifically, seems to be particularly prone to 'fail' when its workers are grossly over-extended for long periods of time (ie, greater than 2-3 weeks).
You sound like you are a relatively small company (under 50 employees, though probably fewer than 30 from the sounds of it). What I would personally suggest is this: be flexible, and do not try to be a larger company before you are. If anything, preference "small, flexible company" type behavior: you're small, you've got the ability to do so still. Being flexible, both with your employees and in general, is an incredibly big strength that larger companies only wish for.
Now, how do you implement such a thing? Well, from personal experience, I think the following might be a good approach (both to the benefit of the employee - making it a favorable/good/preferential place to work):
* Allow for flexible schedules. Thirty hours one week, 60 the next, maybe a couple days off here and there - who cares? Productivity is not measured in hours worked - that's why they are salaried, isn't it? "A dollar a day" - a set cost - isn't exactly the best intention for putting someone under salary. If it is, please reconsider. Personally (and I'm sure this applies to many others) I'm insanely productive for a week or two of 40-60 hour weeks, start to flag, and then rebound a couple weeks later. * give employee incentives for performance, inventiveness, and creativity. If someone implements a new feature in the period of a week that can be deployed, working 80 hours in the process, give them a bonus. If someone works 80 hours cleaning up code (and actually working), * give group incentives for milestones met. This might be difficult depending on the structure of your company and the type of product you're trying to release. * come to grips that you will be operating in the red until you become profitable, and this may take some time. It may never happen, but doing your best (short of abusing your employees) is the best way to approach it. (Throwing money at things does not fix everything, but it sure helps when almost everyone is strapped for cash.) * If deadlines keep slipping, consider finding better managers/management. (If the 'management' is your boss, consider finding another job yourself.)
Of course, doing these things would likely require that your company has some sort of internal structure allowing for groups of people to be gone at any given time, good inter-department communication, and so on. For instance, the interface group should always have someone on hand for the API group to shoot ideas off of; the API group should always have someone available for the interface group to ask questions of; and so on - however you do it, there can't be gaps in communication.
With flexible schedules, it will also obviously be important to keep communication going between independent members. Shelling out a little cash for company smart phones, or some sort of integrated communication system (Exchange, Zimbra, whatever) might be a good idea.
Forcing your salaried programmers to work 50 - even 40 hours - every single week is, well... foolhardy. Anything else is up for debate. Please do consider that people work to live, not live to work: they have families to whom they have responsibilities, desires they which to meet, and lives they wish to live. Leaving the office at 7PM on a Friday is not likely one of them.
Slashdot Mirror
Alcoholism? Broken marriages? Dysfunctional children?
Sorry, I may have missed a couple.
Doesn't always work that way.
We had a client come to us recently and say, "we bought this tool we need to use, but we don't know PowerShell and it needs PS to actually do anything useful".
Me, being the Linux admin, had it land in my lap. Wonderful. I can hack a bit of perl or bash, and some rudimentary C, C#, or C++ or what have you, but I'm not really a programmer. I dislike doing it, but did it anyway. The customer got what they wanted (they were very pleased) and I learned another language in the process.
At no point in this process was there an opportunity to say "I'll use another toolkit". I thought about it, looked a bit, and determined there was nothing that would actually do what the client wanted, short of what they'd actually specified (especially since the project spec said "use this").
The rise of tablets really isn't going to disrupt things as much as columnists like to claim.
Sure it will - just not in the same fashions they think it will. They're too fascinated with the things when, in reality, they're little different than a small laptop or similar, sans a keyboard. The WinCE and similar devices of yesteryear had proportional levels of utility to a desktop 10 years ago - arguably, even in terms of cost. People didn't jump ship then, either: they sucked compared to a full desktop for 90% of what a person might do with computers.
People will just be using less of the following than than previously (instead of 'less PC'):
* Reading traditional print media
* Watching "TV"
* IM'ing
* Casual browsing, maybe.
* Finding a PC to look up something quickly
* Console gaming (consoles have already replaced PCs where they are able to do so in this regard)
Yes, these trends are already in motion to a large degree, but they'll accelerate.
Quite possibly, it means the End of Apple. Apple has not existed in a profitable, quality form under anyone except Jobs; he is the man with the vision.
Without Jobs, Apple is likely to de-orbit, barring a miracle. The company has been driven by him for so long, there is little the company does which is not his Image.
Take him away, and Apple products are likely to become like most other consumer toys: generic. Apple was to the 2000s like Nike/Reebok and Sony were to the 80s/early 90s: an image accessory that everyone simply must have.
No, it's not over yet, but assuming Jobs is actually the one behind the current Apple incarnation, it will be soon.
We shoot and otherwise execute bad human beings every day.
I don't see what sympathy someone's mortal husk should be regarded simply because they're "human".
Likely: the man is dying. He won't be back.
My sympathies to his children, though. They'll likely have a lot of issues to work through given his absence and disregard for their well-being; that kind of thing tends to leave scars. (Jobs is/was an absentee parent, going so far as to deny paternity of at least one of his children.)
BSD users? I thought you liked moving bits around with bar magnets or some such thing?
That said, I imagine you'll not miss much more than you already are. Despite the whole marathon that the various BSD 'package management' systems provide you with, one thing the BSDs typically have going for them that Linux does not is well-designed interfaces. (They may not be usable, and they may not be documented, but they are well designed.)
The irony is that all these subsystems worked pretty damn well in QT3 years ago, and they've only gotten better, since. A lot of the long-running bugs in the various GTK wm subsystems were never really a problem for KDE, and things like the VFS implementations worked much, much better.
If only KDE wasn't such a general memory hog, eh?
With the instrument I can induce the worm to stop, accelerate, lay eggs or experience the illusion of touch
That's what you think it does. What it actually does is sear the alien intelligence's brain with intense, burning pain.
At least we now know who to turn over when the screwworm motherships arrive.
Party like it's 1999.
You really need to break their will - to use the GUI. It's not terribly useful for people who will be using Linux as a server or development platform. They don't need a course to tell them these basic, largely intuitive things.
They need to start from the core of the system; ie, what the system does as it boots.
Walk them through that. Have them read over and analyze the output from dmesg, for starters.
Then start them with some basic console commands. ls, du, who, ps, top, mv, cp, ln, rm, kill, ed/vi/nano, find, whereis/where/which, less/more/cat, and echo are useful, but also be sure to let them know how to find help, and where to look for things - man, apropos, info,, etc. Be sure to include the process of how to use these commands adeptly: man and apropos will go a long, long, long way.
I can't emphasize the use of apropos and man enough. Teach them how to use these things - ie, "how to help yourself" and they will be competent Linux users able to adapt to a myriad of other systems as well (with time).
Touching on hardware interface commands (lspci, lsusb, etc.), system proc files (/proc), exit codes, lsof, and other "programmer useful" things would be nice, too. Package management (dependencies, managers, frontends, interfaces, etc.) would likewise be useful.
Once they understand the kernel boot process, the basics of shell operation, and the system boot process (init/upstart/rc/whatever), they should be well on their way to competence. (Then, of course, there are the usual 'gotchas' everyone runs into in their course of growth - the accidental rm -rf, or killall on a non-Linux system, for instance.)
I would verge towards overloading them with work to encourage them to dig in, instead of going too lean. If you must, grade on a curve - there's a lot to learn here if you're not a competent "professional" already, and a lot of stuff to "unlearn", if coming from the Windows side of things (eg. "errors").
I'm not sure who you're replying to (slashdot's threading kinda sucks at times), but I thought I'd note that pretty much anything "Linux" on FreeBSD usually requires non-trivial Linux binaries to work - usually it's a compatibility package from ports that has the actual binary packages from (say) CentOS and a FreeBSD kernel shim.
I know that their are lots of security issues with the Nvidia proprietary driver supposedly, but I have a sneaky feeling this is because more of the open source community look for a stick to beat nvidia with to try and encourage them to open source their driver. I also think that purely theoretical security issues that only give root to a normal user are not such an issue on single user desktops that are the most likely machines to need graphics acceleration (Personally I disable X on servers).
I've not looked into them, but I would suspect that the security issues with nvidia drivers may be attributable to method in which X implements getting pixels to your screen (client/server).
You have very little imagination.
Girls have boyfriends. They also have female friends. They are not solely keeping these pictures on their hard drives and cameras for personal use (more than likely).
Funny thing about pictures on the Internet: they're trivially copied. Boyfriend copies the picture to his friends (or just one friend), or posts it to a forum: the picture is out, and will live forever on hundreds of 'porn agregators' (lacking a better term), presuming the girl isn't a skag. Likewise, girls are/can be catty: what's stopping them from spreading the nude pictures in a bitter attempt at becoming more popular themselves (thinking it would ridicule the origin)? We're talking about virally social teens, here, not top secret data on government networks: there's literally a thousand and one ways for such pictures to spread to the Internet At Large.
So, in short: it's entirely possible that hundreds of thousands of men and women have viewed, downloaded, etc. child porn and not even be aware of the fact that it is child porn, simply on the basis of "some women look like children and some girls look like women". I recall a couple girls in high school who looked significantly older than 16-18 - and no, I'm not just talking about curves (though that applies too).
It's just like "honest, I thought she was 18, officer!" scenario, except the evidence never disappears and the so-called 'victim' can never grant consent. I would not be surprised if there is legal child porn floating about the internet right now, on "valid" sites which the US federal law enforcement agencies knows about, but allow to exist -so that they can use it as an added charge for someone down the line, if they ned something to vilify them further/want to make sure the charges stick.
I didn't compare Lustre to LVM/RAID - I compared ZFS to it.
What sits on either would be Lustre, obviously. ZFS is significantly superior to RAID + LVM in pretty much every way, barring super-expensive hardware RAID controllers where RAID has a slight trump in and of itself. (Though it should be noted that these RAID controllers would likely provide significant benefit to a ZFS system, too.)
What I have to wonder is: what kind of storage methods or devices does a 'network cluster file system' use? Here's a guess: local storage. Since ZFS is already geared to be a 'network aware' filesystem, in many ways (as much as a filesystem can be, I suppose), it's got fundamental underpinnings (like get/send and the ability to use pools and zvols on other physical hosts transparently) which make it much, much better for clear pictures of your data than ext# on LVM or straight RAID.
To be frank, ext# has more in common with FAT16 than it does ZFS filesystem level functionality (nevermind the fact that ZFS is filesystem, volume manager, and storage controller all in one, doing things which "just a filesystem" could never accomplish on its own).
Yes, because that was obviously what I intended to convey. Thank you for pointing out that your level of reading comprehension is likely very similar to that of a politicians'.
I'll tell you were I got that idea: experience.
Managing filesystems in lvm2, on raid cards - all with their own specific commands - is a real pain in the ass when you've got tens of hosts or more per admin, with many different roles and functionality.
So then you've got to have snmp set up for each of those hosts (often with different controller cards) to monitor those RAID cards status (with the shitty RAID console tool which lacks anything resembling documentation). Then you've got to manage LVM, with its "easily" understood UUIDs. And then you've got to manage your filesystem - whatever that may be - to verify it's intact.
With Lustre, you'll be adding another layer of 'shit I have to monitor'. Even if your hardware is 100% identical across all nodes, is that not a significant pain in the ass to manage for?
ZFS just needs an HBA and 'bare' drives. Baring ZFS itself failing on you (not outside the bounds of reason), you've really only got one/two things to look out for with zfs: data errors and disk failures, both of which are reported with zpool status and can be easily monitored. This is regardless of the version of the system, or even which OS it's running on (Solaris and its derivatives, FreeBSD, and yes, even Linux).
Unlike with RAID, I don't have to contend with the possibility of RAID-5 write hole.
If I need to move to new hardware in a pinch, I can - trivially. I can be a desktop, assuming I've got a suitable controller for all the disks (nothing 'special').
Rebuilds are a fraction of the time as they are on hardware RAID (or mdraid, until recently), because only the actual data is replicated.
Hell, you're going to get more performance out of ZFS than you will from the 'common' vendor (Dell, HP, IBM) RAID cards.
I'm assuming Lustre will scale better on ZFS better than on traditional methods because everything else scales better on ZFS. Growth is easier; management is easier; maintenance is easier. "Storage management" is actually somewhat enjoyable with ZFS, instead of the tedious skulduggery it usually tends to be otherwise.
It does? How do you figure that? You will be somewhat limited compared to other filesystems for 'raw speed', but that's why ZFS has build in read and write cache functionality (via SSD or ramdisk). Unless we're talking about massive amounts of sustained reads and writes, with no time for the disks to catch up, I suspect that (oh) 32Gb of SSD or so would do the trick for most hosts, or 128Gb for a 'high demand' host member to Lustre.
So yeah, if you consider cache, ZFS is going to blow the snot out of anything without it. It would be trivial to configure a zvol to offer total IOPS capability which would saturate the bus bandwidth with small writes, for instance.
If you're archiving, just don't use cache drives.
Besides, I'm reasonably certain that Lustre actually would prefer ZFS as a backend (in terms of performance) because that's what they're using. You can't scale to petabytes of storage with those other filesystems, if for no other reason because they lack the built-in parity and suffer a number of other 'lots of disks' management issues.
Seriously: for the price of storage today, adding an SSD in front of a couple disks to make the performance markedly better is not a significant cost. It's an easy out, and is far cheaper and easier than pretty much any other high-IOPS approach.
You're kinda funny, but there's something your underestimating (or do not simply fully comprehend) about IT.
IT projects scale exponentially in complexity. It might be a 'simple' x units of y, j units of k, a units of b - all tied together with such-and-such technology to distribute whatever on someone else's fabric - in your mind, but a couple things inevitably come up:
* problems exist in wide, homogeneous environments which would never, ever occur on any one of the devices within its production lifetime. Weird shit happens.
* Little compatibility issues ultimately culminate into lack of functionality as your deployment grows.
* There is no "just" - there will always be more end-user support. (Do you really think it'd just be 'seamless' for people to use some quick app on an iPad to view this stuff?)
Most importantly (and the same problem this fucking gov't contractor project had):
* "What now" - the systems may be perfect, but if it doesn't actually improve the real-world application by a significant amount in proportion to the time and effort required to actually use it, it's a worthless product. Most 'complex' IT systems sold by vendors and/or contractors are crap: they take forever to tool up on, and by the time the people/organization is competent with the application (untold hours invested on training and familiarization) it's time to upgrade, replace it, or what have you. Being the government, I'd expect a Microsoft style release schedule - about 3-5 years and maybe 3-5 releases before they actually come across something which the majority of the people would consider 'usable', followed by some regressions and ultimately EOL'ing the product to start over from scratch.
Border security is not a problem that you should look to 'fix' with IT. It can surely be sped up with IT, but in the same way that grunts-on-the-ground have their performance/efficiency improved with IT: communication, survivability, and awareness. Basically, BP needs the same tools the cops have already, as well as many the military has, to do their jobs effectively.
How can anyone claiming to be 'intellectual' in any fashion treat astrological bullshit with anything more serious than disdain? You might as well hold Magic: The Gathering as your religion...
There's an easy-to-implement solution (or four) for this problem which have been tried and done successfully throughout history (assuming the idea is to keep foreign invaders out and/or encourage illegal and likely disloyal foreign nationals already in your country to leave):
* An armed wall with bastions. I suspect the cost would be comparable if you were to have a sane human/machine monitor ratio (hint: monitoring does nothing if there is no physical deterrent worth being concerned about)
* No social sympathy (legally and culturally) for the 'condition'. Allowing the motivated ones to come here only dillutes their own home country's strength of survival. Real, actual efforts to prevent them from working here.
* Go in and shoot the bastards who are ruining the fun in their home country, and take it over as a corporate holding stock, of sorts (hey, the US gets accused of much worse, every time a Republican is in office).
* Allow the people in those border states to legally defend themselves. The bandits who break in, steal, etc. along the border (who are often called 'immigrants') are often treated by LE as victims, whereas the property owners are acted upon harshly if they do anything to protect their livelihood.
I don't suppose "They made (asked) me to do it!" is a legitimate excuse?
Inversely, if we had long names for everything, we'd soon get confused and have insufficient time to actually work.
At a functional level, Lustre (GPL) is to ZFS (CDDL) as CXFS (commercial) is to XFS (GPL) for SGI. They are the upper 'cluster' layer to take advantage of the underlying filesystems' capability. I believe this approach is divergent from that of GFS, due to the upper/lower approach, but I'm not that familiar with clustered filesystems.
However: Arguably, Lustre on ZFS is a mumuchch better option due to ZFSs inherent capability superiorty over XFS. I've liked XFS historically, but ZFS is so drastically superior than anything else out there (in terms of storage management and available capacity and throughput) - all 'out of the box' that it's a no-brainer to use zvols for things other than direct zfs posix access. (For instance, they make great VM iSCSI targets, or local raw disks for VMs, or..)
Side note: the linux zfsonlinux.org port is being successfully used as the base volume manager for Lustre right now, so it is apparently quite capable/stable at that level. (zfsonlinux does not yet have zfs posix support.) Lustre on ZFS It, apparently, scales much better than the traditional LVM/RAID/etc. backend methods.
Where else can you get 6-8 years of rock solid job security at a well paying job with reasonable hours? This is a cost of entry.
No, no it is not. Not unless you get a contract saying so, and the company actually remains solvent.
You fail to realize the potential cost of such hours for employees to the company. Knowledge workers working that much, making bad decisions due to exhaustion or being burnt out (or not really working at all) is a huge, huge risk. Most people can't do it for 5-8 hours a day; even fewer can do it for 10, and almost nobody can do it for 12 and still function optimally (nevermind have a life outside of work, unless drinking themselves to sleep counts).
There are many, many companies which have done this before - see the "dot com boom". You are making a huge bet that the company remains solvent, and that if cutbacks are made, you will not be on that list. So things are going well, but not profitable: how long can the company keep things going at the current rate? If what you've got is working and is tenable, it is a huge risk to change the equation by adding another stressor. You'd be better off to short-fund things and go into the red, then borrow to get where you're going than to sell your non-fungible resources (your employees) short (by short changing them personal time).
Even men at war, fighting for their very lives, have required downtime.
I was essentially 'unemployed' for the better part of three years before finding employment in December 2009. I've got a family, and unemployment isn't going to handle that. I worked pretty much every job imaginable - contracting, construction, misc. physical labor, etc.
Now, I'm salaried at below market rates (even for IT in this low-income area) and working 45-60 hour weeks. I have to occasionally drive around town to client sites and do not get compensated for my mileage above/beyond my time, and the on-site work I do does not negate my routine obligations (as part of my position).
Guess which one I prefer?
I'll give you a hint: my child never went hungry while I was unemployed, and I only begrudgingly collected from the state (if only because I put in years of unemployment insurance to the state, yet was 'ineligible' for some cockamamie reason). Heat and electricity never went off during the winter. Sure, there were days when I rued
But in general, I was happier and less stressed then than I am now: I could sleep in. Any deadline was my own to set, and telling a client to fuck off because they were being offensive or degrading was no big deal. They were, after all, my client, and little was lost aside from a days' work. I was able to be more honest and forward due to not having "my position" on the line: I was my own man, my word was my bond, and my act
No, I probably didn't work much more than 3-4 hours a day, on average (not counting time spent looking for work). We got by.
There is nothing to be gained from overworking yourself. If things come to that ("50 hours or the highway"), it's better for you, as a person, to grab your rifle and head for the woods to find yourself some meat.
Some people like those 10 hour days. If I were single, I'd probably be just fine with that - but I'm not, and doing little things like cleaning up after kids, putting them to bed, and helping with dinner take time. Relationships take time. I'd rather grow old and poor with someone, with children growing into adults, than alone and "getting by" with a few dozen luxuries I've 'managed' on my meager wage.
Let me start off by saying: a universal 50-hour work week, for an IT type position, is stupid beyond belief. Your manager/owner is an idiot for even suggesting such a thing, and apparently does not understand others all that well.
Most people do not thrive on such hours; they flounder and fail. It doesn't matter if it's manual labor, doldrum sales work, or polishing the brass on the Titanic (which this sounds oddly similar to). IT work, specifically, seems to be particularly prone to 'fail' when its workers are grossly over-extended for long periods of time (ie, greater than 2-3 weeks).
You sound like you are a relatively small company (under 50 employees, though probably fewer than 30 from the sounds of it). What I would personally suggest is this: be flexible, and do not try to be a larger company before you are. If anything, preference "small, flexible company" type behavior: you're small, you've got the ability to do so still. Being flexible, both with your employees and in general, is an incredibly big strength that larger companies only wish for.
Now, how do you implement such a thing? Well, from personal experience, I think the following might be a good approach (both to the benefit of the employee - making it a favorable/good/preferential place to work):
* Allow for flexible schedules. Thirty hours one week, 60 the next, maybe a couple days off here and there - who cares? Productivity is not measured in hours worked - that's why they are salaried, isn't it? "A dollar a day" - a set cost - isn't exactly the best intention for putting someone under salary. If it is, please reconsider. Personally (and I'm sure this applies to many others) I'm insanely productive for a week or two of 40-60 hour weeks, start to flag, and then rebound a couple weeks later.
* give employee incentives for performance, inventiveness, and creativity. If someone implements a new feature in the period of a week that can be deployed, working 80 hours in the process, give them a bonus. If someone works 80 hours cleaning up code (and actually working),
* give group incentives for milestones met. This might be difficult depending on the structure of your company and the type of product you're trying to release.
* come to grips that you will be operating in the red until you become profitable, and this may take some time. It may never happen, but doing your best (short of abusing your employees) is the best way to approach it. (Throwing money at things does not fix everything, but it sure helps when almost everyone is strapped for cash.)
* If deadlines keep slipping, consider finding better managers/management. (If the 'management' is your boss, consider finding another job yourself.)
Of course, doing these things would likely require that your company has some sort of internal structure allowing for groups of people to be gone at any given time, good inter-department communication, and so on. For instance, the interface group should always have someone on hand for the API group to shoot ideas off of; the API group should always have someone available for the interface group to ask questions of; and so on - however you do it, there can't be gaps in communication.
With flexible schedules, it will also obviously be important to keep communication going between independent members. Shelling out a little cash for company smart phones, or some sort of integrated communication system (Exchange, Zimbra, whatever) might be a good idea.
Forcing your salaried programmers to work 50 - even 40 hours - every single week is, well... foolhardy. Anything else is up for debate. Please do consider that people work to live, not live to work: they have families to whom they have responsibilities, desires they which to meet, and lives they wish to live. Leaving the office at 7PM on a Friday is not likely one of them.