"With open source, there is a lot of daylight. A lot of people looking at the code. You don't really go around and steal things."
With open source, lots of people are looking at the code. If there's a bug, people will find it (well, that's the theory, at least).
I'm not convinced that lots of people are looking at where the code came from. To take FreeBSD Update as an example, I've engaged in lots of lengthy discussions about technical issues, but nobody has ever asked "did you write this code yourself?"
What they mean when they say that is that the people who own the copyright (or anybody who knows that the copyright isn't owned by the sumbitter) is far more likely to see the misappropriated code in a Free Software/Open Source project than otherwise.
Or do you think it's more likely that I, having written some code for job, will see that code being stolen and used by an ex-coworker in another project at another company which keeps all their source code locked up tighter than a snaredrum?:)
I asked a few months ago about whether or not there are any plans to let people maintain packages (I'm a Debian maintainer, and I'd love to see what things in the Debian toolchain are worth porting over and vice versa).
I was told that it was a long-term goal, 6+ months at least before anybody would be allowed to contribute.
Any idea if those plans have moved forward?
(For reference, if this is shown to anybody else who participated in the discussion at the time, my handle was "ElectricElf")
Why, again, do the slashdot editors seem to imply that college students should have free access to commercial free music? For god's sake, if you are going to go communist for college students, why not just imply that college students should get a free education, room, and board?
Read the fucking article, twit.
The music wasn't free. MIT paid for it. That money came from tuition, donations, grants, and all sorts of things. (And before you say "donation money shouldn't be used...", stop and consider that either the donation money is used for it, or tuition money is used and donation money is used to lower tuition - it's the same bloody thing. It goes into a big pot and then it gets spent.)
Wouldn't a script whose only fuction is to point apt to non-free repositories, hence facilitating the installation of non-free software, preclude Debian from being "100% Free Software?" Is the script any more "free" than free packages that depend on non-free software to run?
Compare it to the current situtation, where the same maintainers use the same keyring and the same servers and the same development boxes and the same mailing lists and the same archive maintenance facilities and the same build daemon infrastructure.
In other words, no, nobody would seriously consider users being able to install non-Free software resulting in Debian not being "100% Free Software". That's somewhat akin to saying that Debian isn't "100% Free Software" because our package tools are capable of installing non-Free software, and because our compilers can compile non-Free software.
To understand what the change actually *means*, you need to understand the vast amount of resources that goes into putting Debian together. The non-Free repositories available on some Debian mirrors piggyback on this infrastructure, and what's being proposed is removing that.
The "real RAID" features you mentioned happen slowly when they're on local disks too - they're hardly realtime. On a big array, expect adding a new disk to take a couple of hours.
Since the timeframe is already in "hours", "2 hours" verses "12 hours" isn't that big a difference in practice. In both cases, it's a fire-and-forget operation.
As for "would need to sync constantly for error-checking/correction" - why would it need to sync constantly? More often than having the disks in one case, that's for sure, since random machines will be shut down every now and then, which simply doesn't happen in a traditional RAID array. But otherwise... don't see where it would be happening.
I used an old SCSI RAID enclosure at my second-last jobsite which didn't like newer drives - the ones which went into standby after <x> seconds of inactivity. Whenever they did that, the controller would mark the spindle as dirty, and it would need to be resynced when it (immediately) got woken up. Now, this was terrible on the drives - that's a *lot* of churning. So we ended up replacing the enclosure. But for a month and a half, even though random spindles were getting resynced every six hours, it was fine. And it was pretty slow too. 8MB/s was pushing it.
Really, all that matters is that a) the performance of the fully-synced array is up to par, and b) machines aren't popping up and down so often that you've got more than one or two resyncs going on at once.
As for RAID5, I do agree that it's probably not the best solution in this case. I recommended 1+0 in a different post. If he desperately wants to use RAID5, then something which does replication between the individual nodes instead of through a central server is definetly in order.
(P.S.: I'd definetly say "Gig-E is consumer hardware":) It's got major advantages over 100mbit [namely better speed, of course, but more important for me is longer cable lengths], and it's about the same price.)
For reference, ext2 blows away XFS on this particular setup. The results for an ext2 filesystem on the same RAID array are: willow,1G,5572,31,5491,2,3754,1,6313,26,7994,1,191.0,1,16,2261,94,+++++,+++,+++++,+++,2245,95,+++++, +++,4296,96
Oh, and you can use bon_csv2txt to conver that into a more readable form;) Just 'echo willow,1G,... | bon_csv2txt'. bon_csv2txt is included in the bonnie++ package.
First off, you aren't going to be able to use this like a real RAID array (a drive can die and you keep on working). The latency and bandwidth of any network that could be reasonably implemented in your home is going to prevent your system from acting like a real RAID array.
I'm currently running some benchmarks on an XFS filesystem built upon a Linux MD RAID1 array, which is in turn built upon a local disk and a remote disk (which is at the end of a switched 100mbit network, the NBD server itself having an 8-year-old drive and a controller which doesn't do DMA).
Which isn't amazing, but quite respectable, especially given that this type of thing wouldn't be used for mass storage of ISOs or whatever, but used for people's "My Documents" folders and their $HOMEs. Notable that a fully local array I have which is made up with an old SCSI controller and some old SCSI disks is about half this speed as far as the filesystem goes, and about a tenth the speed as far as syncing goes.
So, I believe that your assertion of "you aren't going to be able to use this like a real RAID array" is quite incorrect. Especially given that my network isn't particularily fast, my NICs aren't particularily fast, and the remote disk I'm using is dog slow. Replace the NICs with parts that aren't pieces of crap, use Gig-E, and use controllers/drives that aren't 7-8 years old, and you'll get very respectable performance - ESPECIALLY given that the intention isn't to store everything on it, just people's individual files.
P.S.: Yes. I'm repeating myself. I know this. It's deliberate:)
Yes, you could. There would be two options. The first would be to use "old-style" RAID, with an/etc/raidtab which describes which block devices belong to which RAID devices, and the configuration of the RAID device itself.
Secondly, there's "new-style" RAID, which is what I use. When the RAID driver is started, it examines all block devices for what are called "superblocks". Each spindle in the RAID array has a copy of the superblock, describing what array that particular device is a member of, and the parameters for the array.
Given that information, the RAID device is reconstructed. However, as another poster pointed out, the new master will need to have all the NBD devices set up before this will work.
Also as the other poster mentioned, only *ONE* machine can access each NBD device at any one time. So disconnect all the NBD devices from the old master before you turn on the new master.
1) Make all your machines NBD servers. NBD for Linux, NBD for Windows. NBD stands for "network block device" and allows a client to use a server's block device.
2) Set up a master client/server (using Linux or something else with a decent software RAID stack). This machine will be the only NBD *client*, and it will use all the NBD block devices exported by the rest of your network.
3) On the master set up in 2), create a Linux MD RAID array overtop all the NBD devices that are available.
4) Create a filesystem on the brand-spanking-new multi-machine RAID array.
5) Export it back to the other machines via Samba or NFS or AFS or what have you.
Why does only one machine (the "master server") access the NBD devices, you ask? Because for a given block device, there can only be one client accessing it safely. Thus, if you want to make the RAID array available to anything other than the machine which is *running* the array off the NBD devices, you need to use something which allows concurrent access; something like NFS, Samba, or AFS.
As another poster has said, "selective enforcement" is irrelevant as far as copyright is concerned. You're free to license your copyright to somebody and then let them do whatever the hell they want - regardless of the terms of the license, you don't lose copyright.
Now, if you fail to enforce *trademarks*, you can lose them.
At least where I work, the general turnaround time is about six months. And even then, they only do the servers, and they only patch the most critical of vulnerabilities.
We're looking at 2,500 servers here, but still - six months? Absurd.
(No, I'm not directly involved in the process, though I *did* write many of the docs about it that they use. They take forever to do the simplest of tasks.)
I'm not saying I'm an MS-apologist, but shouldn't decisions based on taxpayer money usually be based on cost analysis? A Blanket policy against MS, without allowing for a competitive bidding process or even alternative analysis doesn't seem right.
The article mentions that one of the primary reasons for choosing FOSS over Microsoft software was that of cost.
Other little things like accessibility, access to the code, and reliability were taken into account as well.
Though you didn't, I see a lot of kneejerk reactions all over the place (not just here in Slashdot, but amongst coworkers as well) along the lines of "they shouldn't be dictating what software will be used, they should let people use whatever they want!"
I work for a Crown corporation here in Canada (something halfway between a legal monopoly and a government ministry), and I would _love_ if Those Above would make edicts like this. Frankly, my direct superiors are _not_ capable of making good decisions. And they're the ones purchasing the software. No word of a joke, but just recently my boss signed a cheque for some $600,000 to license some software that was terribly buggy and unreliable. It was a trivial piece of code, too - it could have been developed in-house by one of our talented programmers for about $15k. And we'd have had the source and a pool of people who were already quite familiar with it. The rollout for the software that was actually bought will take six months and cost another $140,000. The in-house solution could be rolled out in two or three months (and that's including development time) for a similar cost. Why did my boss decide this? Fucked if I know. His reasoning is gibberish. All the vendors were taking him out to really nice retreats, so I bet no matter what we'd have gone with an out-sourced solution (nobody in-house is going to drop $8k to send him to a spa^Wworkshop for a weekend), but I don't think this guy chose the worst vendor 'cause they spent the most money, I think they were just able to swindle him the best.
Moral of the story? It's very possible that in this case, the State is seeing millions of taxpayer dollars being pissed away on substandard solutions when they know damned well that better solutions are available at a fraction of the purchase price and a third the maintenance cost. That's how it's like where I work, and all the other clients I've visited (mostly fairly large business) are in similar trouble - even if they don't know it yet.
"superier to what? I missed the point only half as much as you did, at least it it appears to me so."
In the context, FOSS is superior to closed-source software whose EULA forbids the publishing of benchmarks.
For instance, in this case the published benchmarks show a number of tasks that OpenBSD is very poorly-suited for. Last guy *I* knew who tried to publish similar benchmarks about Oracle compared to MS SQL Server got cease-and-desisted by the Oracle folk.
Do you have a few cites for that claim? I wasn't aware that there were a huge number of monopoly vendors. How big is your sample size?
If you're looking specifically at the software industry, then yeah, there aren't _all_ that many huge monopolies (note "huge" was your word, not mine:).
I was, however, being more general. General Motors, Ford, Bell, cable companies, municipal utilities, makers of jeans, music industry associations, etc., etc., have all been guilty of this at one point or another, and they were all smacked down for it, very hard, by the government.
However, if you want to apply the same thought *just* to the software industry you can - there's a form of micro-monopoly called "vendor lock-in". That is to say, holding one's customers hostage by making it ludicrously expensive to switch to another vendor. For instance, many change management database vendors have gone to great length to obfuscate their on-disk format and the access methods to them, in order to lock their customers in. I won't mention any names (if one of my clients saw me saying something like this, and naming names, I'd get in some serious shit), but pick the top four and you're set.
How can 4 weeks be considered a reasonable amount of time to fix a bug and issue a patch when IT people who merely DEPLOY the frick'in patch complain that 4 weeks isn't enough time to deploy a patch?
Most of my clients have a few hundred computers. When it's important, they'll usually get a patch deployed on every machine in a few hours (work split between a halfdozen people).
There are tools that scale very well. One of my clients has 4,377 servers (just looked that up), and somewhere around 14,000 workstations. These guys aren't particularily good, and yeah, it takes them months to get even a single patch reasonably widely-deployed, and 9 times out of 10 there are still a few thousand machines which don't have it (but which they think do:).
That's an expertise problem, though - there are tools they could be using which they aren't, tools that are provided at no cost from Microsoft, which could make it much faster. They also don't standardise their software installs, almost each and every machine is unique in some way - that's a truly hellish situation.
If my experience isn't the general experience (with most of my clients being able to deploy patches in hours), then I might suggest that the problem is that it's such a god-forsaken risk, installing MS patches. Sure, 97 times out of a hundred they don't cause any problems, but it isn't "97 patches out of a hundred", it's "97 installs out of a hundred". That usually means days and days spent fixing and tweaking and poking the machine which broke. This is another area where Microsoft could improve - it's one thing to have a fix, it's quite another to have a fix which breaks things.
All that being said, however, I'd like to point out that it doesn't matter how long it takes some people to install the patches. I'm demanding Microsoft to do what it can. It's got 30 or 40 billion in the bank, it can afford to hire people who are specialists on specific pieces of code, such that if a problem ever occurs they can get a *GOOD* patch right out the door.
Maybe you don't care if your systems are vulnerable to exploits which were being traded around the black-hat communities six months ago, but that's not my choice, nor is it the choice of my clients.
P.S.: Four weeks is extraordinarily generous. Except for all but the hairest vulnerabilities, the fixes themselves are generally finished within hours, and with a proper lab and staff they can be tested on hundreds of different configurations within the next few days.
I sincerely hope that if Microsoft doesn't fix each and every valid vulnerability that was listed on that page, within six months, that the page gets restored.
It has been proven time and again and again and again that vendors, especially monopoly vendors, will not fix their systems in a timely manner unless they're pressured to. And by "timely manner", I mean within four weeks.
The last five or six MS security bulletins I've seen had lapses of between SIX AND NINE MONTHS between the reporting of the problem and the release of the patch.
So two things:
1) If Microsoft doesn't fix all the currently-known vulnerabilities within six months, somebody should take it upon themselves to start tracking them again 2) If Microsoft can't get their act together and release patches for new vulnerabilities in a timely manner (instead opting to waffle for six months while real people's systems are getting exploited because MS is _never_ the only entity to know a vulnerability, and it's almost guaranteed that somebody with nefarious intentions does), then somebody should take it upon themselves to start disseminating as much information as is required for *real* preventative measures to be put in place
I'm all for giving them one more chance, but I'm not willing to sacrifice my clients' systems by changing my standards for this "chance". They either do what they should do, or they have to deal with me telling my clients exactly what they need to do to protect themselves from a given vulnerability - and that information would almost certainly be enough for a black-hat to use if it ever got leaked.
If you think my standards are too high, consider that other vendors whose software is used on systems which literally control life-or-death systems often release fixes within hours and days, not weeks and months.
That is truly childish. The real assholes at SCO are the suits and money-grubbing lawyers responsible for this charade. A code monkey in the trenches who needs a job to pay the bills isn't necessarily an enemy of open source.
This is part of the problem with North America these days. People divest themselves of any responsibility for their actions. "It's not my fault 10,000 people died from toxic waste poisoning, I was just doing my job, delivering the barrels to the river and dumping them." How about, "Yeah, so what if I killed a one-room school full of children? Those were my orders."
In SCO's case, they're damaging the livelyhoods of hundreds of thousands if not millions of people, and doing their damned best to set back Open Source and Free Software 20 years, just when people the world over are starting to wake up and realise that, hey, it's actually a pretty decent way to do things.
So, yes, I wouldn't hire the code-monkey unless his resume stated "Left SCO due to a moral conflict." or similar. Otherwise, he helped them do what they were doing. Maybe he can sleep better at night thinking, "I just did my job," but that doesn't cut it for me.
If your company is truly evil, it is your duty to at the very least quit. I've done it myself. And yes, I had obligations too. If I can do it you can do it, so you get no sympathy from me. You should hide in shame the fact that you ever worked for SCO. Which is what the employer cited is asking for - don't include it on your resume. You aren't allowed to take credit for being even a small part of a group that's hellbent on extortion.
What amazes me isn't that these people were able to restore service to their customers in 72 hours. They used standard systems administration techniques. BGP was specifically mentioned.
No, what amazes me is that this is news. The IT industry is so full of idiots and morons and MCSEs that taking basic precautions earns you a six-figure salary and news coverage. These folks didn't even have off-site backups, it was luck that they were able to resume business operations (ie: billing) so soon.
Moral of the story? When automobile manufacturers start getting press coverage for doing a great job because unlike their competition, they install brakes in their vehicles, you know that the top-tier IT managers and executives have switched industries.
A) Would be an improvement over the current situation. B) Would also be an improvement over the current situation (in my experience), but not as good as A).
Come to think of it, A) would only be good if the vast majority of people worked from home. Not just "more". If you have 20,000 people going into offices, and 10,000 at home, you'll still get nailed.
C) Why outsource? Why not, instead, hire *competent* people who are available over the course of the company's lifetime to deal with changing circumstances? Ontario Hydro has outsourced all its IT stuff to Inergi and New Horizon.
Outsourcing is an evil part of the IT industry - people pay obscene sums of money for worthless junk (worse than what they'd get in-house, in my experience).
D) Giving up is not an option:)
I would, instead, propose a real solution:
E) Hire competent people. Hire as many as you need. Hire competent managers. Hire as many as you need. LET THEM DO THEIR JOBS. Do not tell them that everybody needs to run Windows. Let them weigh the costs and the needs of the company, and make a decision. Live with that decision knowing that you hired good people and that this is really the best possible solution.
(I know full well I'm dreaming. I don't expect companies to be competent at hiring competent people for at least another decade. Maybe not even then, maybe it'll be much longer. But I can hope. Christ, the stories I could tell... it's truly systemic incompetence. Incompetence from the VPs responsible for IT to incompetence at the lowest-level grunt. Outside the IT department the incompetence is in the HR department for hiring these people in the first place.)
his indicates that the network that the train signaling stations are on is not protected by firewalls, at least to block ports 135 and 444 where the DCOM vulnerability is attacked.
That is a silly conclusion to come to. Presumably they're also implying the same about the power grid.
I have first-hand experience with Ontario Hydro's IT nework (now Hydro One's IT network;) and I gotta say - they have firewalls up the wazoo. And this is the problem. They rely on border security. However, on networks as large as the ones being discussed, border security doesn't cut it. There are too many entry vectors. People reading email, people browsing the web, and oh my god people with laptops - the pain the pain.
So before you go thinking "they aren't even taking precautions that would have saved them! Fire them!" understand that it's *exactly* that attitude which caused the networks to go down in the first place - the common misconception the a firewall is a magic wand that will solve all their ills.
Border security does NOT cut it when you run insecure software on the inside, boys and girls. And you can take that to the bank.
lol, you know I realised that after I'd posted the second one only to see that the first one had been modded way up in the meantime?:)
But in all seriousness, it doesn't matter - I had 50 the first (and incidentally, only) time I checked my karma, and that was after the cap was put in place (very shortly after, in fact). God knows what it was before.
For those who understand how this works, it is not a bad thing. However the hardware is being marketed to the general public.
As a result you can expect that people who see the 5 x faster than b are going to completely skip the small text that disclaims this on the back of the box. I think everyone would be surprised if this did not include a significant number of ostensibly technically inclined writers who will report that they did not see the improvements advertised, and who will subsequently give the technology a bad rap.
Okay, I see where you're coming from. If it's being heavily marketed as being 5x faster than 802.11b and as being compatible with 802.11b (at the same time), then yeah, I see.
I'm not sure I agree with the end-result though. I think anybody likely to notice the difference will read the box. I also don't think 802.11b is all that popular with non-tech-enthusiasts. I certainly don't know anybody who has it:) That isn't to say there aren't a lot of people using 802.11b who wouldn't know to read the box, just that *I* don't know any of them.
Even though I think that's the case, I will hold in contempt any company that markets it as being 5 times faster and compatible at the same time. But I suppose, this being Slashdot, that goes without saying:)
(Sorry for the parent post, I made a typo. Just s/802.11a/802.11b/ in the second bullet point. "oops":)
Okay, I read the article, and here's a basic rundown (I think:):
802.11g in a homogenous network (ie: only 802.11g access points) is faster than 802.11b (by a factor of five or so) and 802.11a (just a bit faster).
802.11g in a heterogenous network (ie: some 802.11g access points, and some 802.11b access points which have been "assosiated" with the same network as the 802.11g access points) is rougly 1.5 to 2.5 times faster than 802.11b, depending on the type of collision-detection algorithm used. This setup is not as fast as 802.11a.
So, to sum up the summary: If you start replacing your 802.11b access points with 802.11g access points, you'll see some performance gain with 802.11g client devices right away. When all your 802.11b client devices are gone (and thus all the 802.11b access points), it'll be way faster. Faster even than 802.11a.
Why is this billed as a bad thing? You get compatibility with your existing infrastructure, a little bonus performance now, and when the time comes, bang you get a big boost.
This is the kind of thing that sysadmins such as myself LOVE:)
Slashdot Mirror
What they mean when they say that is that the people who own the copyright (or anybody who knows that the copyright isn't owned by the sumbitter) is far more likely to see the misappropriated code in a Free Software/Open Source project than otherwise.
Or do you think it's more likely that I, having written some code for job, will see that code being stolen and used by an ex-coworker in another project at another company which keeps all their source code locked up tighter than a snaredrum? :)
I asked a few months ago about whether or not there are any plans to let people maintain packages (I'm a Debian maintainer, and I'd love to see what things in the Debian toolchain are worth porting over and vice versa).
I was told that it was a long-term goal, 6+ months at least before anybody would be allowed to contribute.
Any idea if those plans have moved forward?
(For reference, if this is shown to anybody else who participated in the discussion at the time, my handle was "ElectricElf")
Read the fucking article, twit.
The music wasn't free. MIT paid for it. That money came from tuition, donations, grants, and all sorts of things. (And before you say "donation money shouldn't be used ...", stop and consider that either the donation money is used for it, or tuition money is used and donation money is used to lower tuition - it's the same bloody thing. It goes into a big pot and then it gets spent.)
Compare it to the current situtation, where the same maintainers use the same keyring and the same servers and the same development boxes and the same mailing lists and the same archive maintenance facilities and the same build daemon infrastructure.
In other words, no, nobody would seriously consider users being able to install non-Free software resulting in Debian not being "100% Free Software". That's somewhat akin to saying that Debian isn't "100% Free Software" because our package tools are capable of installing non-Free software, and because our compilers can compile non-Free software.
To understand what the change actually *means*, you need to understand the vast amount of resources that goes into putting Debian together. The non-Free repositories available on some Debian mirrors piggyback on this infrastructure, and what's being proposed is removing that.
The "real RAID" features you mentioned happen slowly when they're on local disks too - they're hardly realtime. On a big array, expect adding a new disk to take a couple of hours.
... don't see where it would be happening.
:) It's got major advantages over 100mbit [namely better speed, of course, but more important for me is longer cable lengths], and it's about the same price.)
Since the timeframe is already in "hours", "2 hours" verses "12 hours" isn't that big a difference in practice. In both cases, it's a fire-and-forget operation.
As for "would need to sync constantly for error-checking/correction" - why would it need to sync constantly? More often than having the disks in one case, that's for sure, since random machines will be shut down every now and then, which simply doesn't happen in a traditional RAID array. But otherwise
I used an old SCSI RAID enclosure at my second-last jobsite which didn't like newer drives - the ones which went into standby after <x> seconds of inactivity. Whenever they did that, the controller would mark the spindle as dirty, and it would need to be resynced when it (immediately) got woken up. Now, this was terrible on the drives - that's a *lot* of churning. So we ended up replacing the enclosure. But for a month and a half, even though random spindles were getting resynced every six hours, it was fine. And it was pretty slow too. 8MB/s was pushing it.
Really, all that matters is that a) the performance of the fully-synced array is up to par, and b) machines aren't popping up and down so often that you've got more than one or two resyncs going on at once.
As for RAID5, I do agree that it's probably not the best solution in this case. I recommended 1+0 in a different post. If he desperately wants to use RAID5, then something which does replication between the individual nodes instead of through a central server is definetly in order.
(P.S.: I'd definetly say "Gig-E is consumer hardware"
For reference, ext2 blows away XFS on this particular setup. The results for an ext2 filesystem on the same RAID array are: willow,1G,5572,31,5491,2,3754,1,6313,26,7994,1,191 .0,1,16,2261,94,+++++,+++,+++++,+++,2245,95,+++++, +++,4296,96
;) Just 'echo willow,1G,... | bon_csv2txt'. bon_csv2txt is included in the bonnie++ package.
Oh, and you can use bon_csv2txt to conver that into a more readable form
I'm currently running some benchmarks on an XFS filesystem built upon a Linux MD RAID1 array, which is in turn built upon a local disk and a remote disk (which is at the end of a switched 100mbit network, the NBD server itself having an 8-year-old drive and a controller which doesn't do DMA).
[ dbharris@willow: ~/ ]$ cat /proc/mdstat
Personalities : [raid0] [raid1]
md1 : active raid1 nbd0[1] dm-5[0]
1888192 blocks [2/2] [UU]
It takes approximately 10 minutes for a 1.8G array to sync. That's respectable. It's not blazing fast, but it's respectable.
The bonnie++ scores are:
willow,1G,5086,31,4766,2,2873,1,6377,27,8655,2,1 58.7,1,16,878,18,+++++,+++,766,14,880,18,+++++,+++ ,595,13
Which isn't amazing, but quite respectable, especially given that this type of thing wouldn't be used for mass storage of ISOs or whatever, but used for people's "My Documents" folders and their $HOMEs. Notable that a fully local array I have which is made up with an old SCSI controller and some old SCSI disks is about half this speed as far as the filesystem goes, and about a tenth the speed as far as syncing goes.
So, I believe that your assertion of "you aren't going to be able to use this like a real RAID array" is quite incorrect. Especially given that my network isn't particularily fast, my NICs aren't particularily fast, and the remote disk I'm using is dog slow. Replace the NICs with parts that aren't pieces of crap, use Gig-E, and use controllers/drives that aren't 7-8 years old, and you'll get very respectable performance - ESPECIALLY given that the intention isn't to store everything on it, just people's individual files.
P.S.: Yes. I'm repeating myself. I know this. It's deliberate :)
Yes, you could. There would be two options. The first would be to use "old-style" RAID, with an /etc/raidtab which describes which block devices belong to which RAID devices, and the configuration of the RAID device itself.
Secondly, there's "new-style" RAID, which is what I use. When the RAID driver is started, it examines all block devices for what are called "superblocks". Each spindle in the RAID array has a copy of the superblock, describing what array that particular device is a member of, and the parameters for the array.
Given that information, the RAID device is reconstructed. However, as another poster pointed out, the new master will need to have all the NBD devices set up before this will work.
Also as the other poster mentioned, only *ONE* machine can access each NBD device at any one time. So disconnect all the NBD devices from the old master before you turn on the new master.
Performance could potentially be very terrible, especially with RAID5
That being said, do some benchmarks. RAID1+0 might be more sane. (That is, a RAID1 array overtop a RAID0 array.)
Just to clarify what this guy is saying:
1) Make all your machines NBD servers. NBD for Linux, NBD for Windows. NBD stands for "network block device" and allows a client to use a server's block device.
2) Set up a master client/server (using Linux or something else with a decent software RAID stack). This machine will be the only NBD *client*, and it will use all the NBD block devices exported by the rest of your network.
3) On the master set up in 2), create a Linux MD RAID array overtop all the NBD devices that are available.
4) Create a filesystem on the brand-spanking-new multi-machine RAID array.
5) Export it back to the other machines via Samba or NFS or AFS or what have you.
Why does only one machine (the "master server") access the NBD devices, you ask? Because for a given block device, there can only be one client accessing it safely. Thus, if you want to make the RAID array available to anything other than the machine which is *running* the array off the NBD devices, you need to use something which allows concurrent access; something like NFS, Samba, or AFS.
Hope that clears it up a bit.
bitch moan moan bitch toy bitch moan stuff moan moan bitch moan bitch not useful bitch bitch bitch bitch moan bitch phone moan moan bitch
As another poster has said, "selective enforcement" is irrelevant as far as copyright is concerned. You're free to license your copyright to somebody and then let them do whatever the hell they want - regardless of the terms of the license, you don't lose copyright.
Now, if you fail to enforce *trademarks*, you can lose them.
At least where I work, the general turnaround time is about six months. And even then, they only do the servers, and they only patch the most critical of vulnerabilities.
We're looking at 2,500 servers here, but still - six months? Absurd.
(No, I'm not directly involved in the process, though I *did* write many of the docs about it that they use. They take forever to do the simplest of tasks.)
The article mentions that one of the primary reasons for choosing FOSS over Microsoft software was that of cost.
Other little things like accessibility, access to the code, and reliability were taken into account as well.
Though you didn't, I see a lot of kneejerk reactions all over the place (not just here in Slashdot, but amongst coworkers as well) along the lines of "they shouldn't be dictating what software will be used, they should let people use whatever they want!"
I work for a Crown corporation here in Canada (something halfway between a legal monopoly and a government ministry), and I would _love_ if Those Above would make edicts like this. Frankly, my direct superiors are _not_ capable of making good decisions. And they're the ones purchasing the software. No word of a joke, but just recently my boss signed a cheque for some $600,000 to license some software that was terribly buggy and unreliable. It was a trivial piece of code, too - it could have been developed in-house by one of our talented programmers for about $15k. And we'd have had the source and a pool of people who were already quite familiar with it. The rollout for the software that was actually bought will take six months and cost another $140,000. The in-house solution could be rolled out in two or three months (and that's including development time) for a similar cost. Why did my boss decide this? Fucked if I know. His reasoning is gibberish. All the vendors were taking him out to really nice retreats, so I bet no matter what we'd have gone with an out-sourced solution (nobody in-house is going to drop $8k to send him to a spa^Wworkshop for a weekend), but I don't think this guy chose the worst vendor 'cause they spent the most money, I think they were just able to swindle him the best.
Moral of the story? It's very possible that in this case, the State is seeing millions of taxpayer dollars being pissed away on substandard solutions when they know damned well that better solutions are available at a fraction of the purchase price and a third the maintenance cost. That's how it's like where I work, and all the other clients I've visited (mostly fairly large business) are in similar trouble - even if they don't know it yet.
"superier to what? I missed the point only half as much as you did, at least it it appears to me so."
:)
In the context, FOSS is superior to closed-source software whose EULA forbids the publishing of benchmarks.
For instance, in this case the published benchmarks show a number of tasks that OpenBSD is very poorly-suited for. Last guy *I* knew who tried to publish similar benchmarks about Oracle compared to MS SQL Server got cease-and-desisted by the Oracle folk.
Cappice?
If you're looking specifically at the software industry, then yeah, there aren't _all_ that many huge monopolies (note "huge" was your word, not mine :).
I was, however, being more general. General Motors, Ford, Bell, cable companies, municipal utilities, makers of jeans, music industry associations, etc., etc., have all been guilty of this at one point or another, and they were all smacked down for it, very hard, by the government.
However, if you want to apply the same thought *just* to the software industry you can - there's a form of micro-monopoly called "vendor lock-in". That is to say, holding one's customers hostage by making it ludicrously expensive to switch to another vendor. For instance, many change management database vendors have gone to great length to obfuscate their on-disk format and the access methods to them, in order to lock their customers in. I won't mention any names (if one of my clients saw me saying something like this, and naming names, I'd get in some serious shit), but pick the top four and you're set.
Most of my clients have a few hundred computers. When it's important, they'll usually get a patch deployed on every machine in a few hours (work split between a halfdozen people).
There are tools that scale very well. One of my clients has 4,377 servers (just looked that up), and somewhere around 14,000 workstations. These guys aren't particularily good, and yeah, it takes them months to get even a single patch reasonably widely-deployed, and 9 times out of 10 there are still a few thousand machines which don't have it (but which they think do :).
That's an expertise problem, though - there are tools they could be using which they aren't, tools that are provided at no cost from Microsoft, which could make it much faster. They also don't standardise their software installs, almost each and every machine is unique in some way - that's a truly hellish situation.
If my experience isn't the general experience (with most of my clients being able to deploy patches in hours), then I might suggest that the problem is that it's such a god-forsaken risk, installing MS patches. Sure, 97 times out of a hundred they don't cause any problems, but it isn't "97 patches out of a hundred", it's "97 installs out of a hundred". That usually means days and days spent fixing and tweaking and poking the machine which broke. This is another area where Microsoft could improve - it's one thing to have a fix, it's quite another to have a fix which breaks things.
All that being said, however, I'd like to point out that it doesn't matter how long it takes some people to install the patches. I'm demanding Microsoft to do what it can. It's got 30 or 40 billion in the bank, it can afford to hire people who are specialists on specific pieces of code, such that if a problem ever occurs they can get a *GOOD* patch right out the door.
Maybe you don't care if your systems are vulnerable to exploits which were being traded around the black-hat communities six months ago, but that's not my choice, nor is it the choice of my clients.
P.S.: Four weeks is extraordinarily generous. Except for all but the hairest vulnerabilities, the fixes themselves are generally finished within hours, and with a proper lab and staff they can be tested on hundreds of different configurations within the next few days.
I sincerely hope that if Microsoft doesn't fix each and every valid vulnerability that was listed on that page, within six months, that the page gets restored.
It has been proven time and again and again and again that vendors, especially monopoly vendors, will not fix their systems in a timely manner unless they're pressured to. And by "timely manner", I mean within four weeks.
The last five or six MS security bulletins I've seen had lapses of between SIX AND NINE MONTHS between the reporting of the problem and the release of the patch.
So two things:
1) If Microsoft doesn't fix all the currently-known vulnerabilities within six months, somebody should take it upon themselves to start tracking them again
2) If Microsoft can't get their act together and release patches for new vulnerabilities in a timely manner (instead opting to waffle for six months while real people's systems are getting exploited because MS is _never_ the only entity to know a vulnerability, and it's almost guaranteed that somebody with nefarious intentions does), then somebody should take it upon themselves to start disseminating as much information as is required for *real* preventative measures to be put in place
I'm all for giving them one more chance, but I'm not willing to sacrifice my clients' systems by changing my standards for this "chance". They either do what they should do, or they have to deal with me telling my clients exactly what they need to do to protect themselves from a given vulnerability - and that information would almost certainly be enough for a black-hat to use if it ever got leaked.
If you think my standards are too high, consider that other vendors whose software is used on systems which literally control life-or-death systems often release fixes within hours and days, not weeks and months.
This is part of the problem with North America these days. People divest themselves of any responsibility for their actions. "It's not my fault 10,000 people died from toxic waste poisoning, I was just doing my job, delivering the barrels to the river and dumping them." How about, "Yeah, so what if I killed a one-room school full of children? Those were my orders."
In SCO's case, they're damaging the livelyhoods of hundreds of thousands if not millions of people, and doing their damned best to set back Open Source and Free Software 20 years, just when people the world over are starting to wake up and realise that, hey, it's actually a pretty decent way to do things.
So, yes, I wouldn't hire the code-monkey unless his resume stated "Left SCO due to a moral conflict." or similar. Otherwise, he helped them do what they were doing. Maybe he can sleep better at night thinking, "I just did my job," but that doesn't cut it for me.
If your company is truly evil, it is your duty to at the very least quit. I've done it myself. And yes, I had obligations too. If I can do it you can do it, so you get no sympathy from me. You should hide in shame the fact that you ever worked for SCO. Which is what the employer cited is asking for - don't include it on your resume. You aren't allowed to take credit for being even a small part of a group that's hellbent on extortion.
What amazes me isn't that these people were able to restore service to their customers in 72 hours. They used standard systems administration techniques. BGP was specifically mentioned.
No, what amazes me is that this is news. The IT industry is so full of idiots and morons and MCSEs that taking basic precautions earns you a six-figure salary and news coverage. These folks didn't even have off-site backups, it was luck that they were able to resume business operations (ie: billing) so soon.
Moral of the story? When automobile manufacturers start getting press coverage for doing a great job because unlike their competition, they install brakes in their vehicles, you know that the top-tier IT managers and executives have switched industries.
A) Would be an improvement over the current situation.
:)
... it's truly systemic incompetence. Incompetence from the VPs responsible for IT to incompetence at the lowest-level grunt. Outside the IT department the incompetence is in the HR department for hiring these people in the first place.)
B) Would also be an improvement over the current situation (in my experience), but not as good as A).
Come to think of it, A) would only be good if the vast majority of people worked from home. Not just "more". If you have 20,000 people going into offices, and 10,000 at home, you'll still get nailed.
C) Why outsource? Why not, instead, hire *competent* people who are available over the course of the company's lifetime to deal with changing circumstances? Ontario Hydro has outsourced all its IT stuff to Inergi and New Horizon.
Outsourcing is an evil part of the IT industry - people pay obscene sums of money for worthless junk (worse than what they'd get in-house, in my experience).
D) Giving up is not an option
I would, instead, propose a real solution:
E) Hire competent people. Hire as many as you need. Hire competent managers. Hire as many as you need. LET THEM DO THEIR JOBS. Do not tell them that everybody needs to run Windows. Let them weigh the costs and the needs of the company, and make a decision. Live with that decision knowing that you hired good people and that this is really the best possible solution.
(I know full well I'm dreaming. I don't expect companies to be competent at hiring competent people for at least another decade. Maybe not even then, maybe it'll be much longer. But I can hope. Christ, the stories I could tell
That is a silly conclusion to come to. Presumably they're also implying the same about the power grid.
I have first-hand experience with Ontario Hydro's IT nework (now Hydro One's IT network ;) and I gotta say - they have firewalls up the wazoo. And this is the problem. They rely on border security. However, on networks as large as the ones being discussed, border security doesn't cut it. There are too many entry vectors. People reading email, people browsing the web, and oh my god people with laptops - the pain the pain.
So before you go thinking "they aren't even taking precautions that would have saved them! Fire them!" understand that it's *exactly* that attitude which caused the networks to go down in the first place - the common misconception the a firewall is a magic wand that will solve all their ills.
Border security does NOT cut it when you run insecure software on the inside, boys and girls. And you can take that to the bank.
lol, you know I realised that after I'd posted the second one only to see that the first one had been modded way up in the meantime? :)
But in all seriousness, it doesn't matter - I had 50 the first (and incidentally, only) time I checked my karma, and that was after the cap was put in place (very shortly after, in fact). God knows what it was before.
Okay, I see where you're coming from. If it's being heavily marketed as being 5x faster than 802.11b and as being compatible with 802.11b (at the same time), then yeah, I see.
I'm not sure I agree with the end-result though. I think anybody likely to notice the difference will read the box. I also don't think 802.11b is all that popular with non-tech-enthusiasts. I certainly don't know anybody who has it :) That isn't to say there aren't a lot of people using 802.11b who wouldn't know to read the box, just that *I* don't know any of them.
Even though I think that's the case, I will hold in contempt any company that markets it as being 5 times faster and compatible at the same time. But I suppose, this being Slashdot, that goes without saying :)
(Sorry for the parent post, I made a typo. Just s/802.11a/802.11b/ in the second bullet point. "oops" :)
Okay, I read the article, and here's a basic rundown (I think :):
So, to sum up the summary: If you start replacing your 802.11b access points with 802.11g access points, you'll see some performance gain with 802.11g client devices right away. When all your 802.11b client devices are gone (and thus all the 802.11b access points), it'll be way faster. Faster even than 802.11a.
Why is this billed as a bad thing? You get compatibility with your existing infrastructure, a little bonus performance now, and when the time comes, bang you get a big boost.
This is the kind of thing that sysadmins such as myself LOVE :)