Go find a copy of Source Off-Site. Then you can hit VSS crap from just about anywhere. Yeap, it sucks as much as you'd think it would... crap ontop of crap is just a bigger pile of...
I even tried using SS.EXE under linux (with a sutable emulator.) Just don't use VSS. Even CVS is better -- and that's just sad.
More accurately: BitMover loses all of it's advertising.
Seriously, have you ever head of BitKeeper outside of Linux discussions? Have you ever seen an ad for BitKeeper anywhere? Even if the quoted figures are right ($500,000/year), that's pretty cheap advertising for the amount of coverage.
(I've known about BK/BitMover for a long time simply because I know of Larry McVoy. But aside from that association, I've never heard of either.)
Wrong, o' annonymous asshole. One can continue to get patches and tarballs from the usual place(s) and send patches to maintainers and lists the same as has been done for over a decade.
There is absolutely zero requirement for anyone to use bitkeeper. It's easier for Linus to bk pull from someone's tree but there was never a requirement made of anyone to do it that way. Plus, the main tree is only writable by Linus (and maybe a few others), so one cannot bk push their changes into the main tree anyway. (They still have to be sent as a patch or pulled by Linus.)
So, I'll say it again:
There is
absolutely zero requirement for anyone to use bitkeeper.
There should have been an organized effort at creating an OSS project that would work as well (or, preferably better) than BK. If there wasn't an OSS tool that was the best choice, one should have been developed.
That's just it. The OSS world never creates one wheel, and rarely finishes one before embarking on the next.
Linus chose BK because it was the only thing available at the time to do what was needed. It's not about one being better than another. It comes down to meeting a set of criteria. Several years (and a lot of bitching) later and we're still at the same spot... there still aren't any OSS projects to meet all of the requirements. BK/Free has been around for 5 years; Linus has been using it for 3 years, so where's all the alternatives from those that have been bitching constantly against the use of BK? Well? I'm f***ing waiting. If you don't have something that'll do the job, then you should shutup and let me use what ever'll do the job. That's the thing the opponents refuse to accept. ("I don't need to invent a wheel; Larry has kindly give me one of his.")
Both -- as they are the same thing. BK brings conciderable productivity to the process. No open source tools provide anything close to what BK is doing. Linus knows this already, but he's been left no choice. ('tho, through no fault of his own.)
Any SCM would help vs. the decade old process of patch and manually resovle the conflicts -- and there are always conflicts. This is simply because it forces a common ancestry in every development arm. diff and patch don't carry any history or version graphs. BK takes this a little too far, IMO, by hanging everything off change sets -- a single change suddenly is dependant on every change in every file that comes before it. (This is good for commercial development as every tree is supposed to be the same. However, for the linux kernel, there are too many side branches with changes unfit for the main branch that prevent easy patch integration -- main can never pull patches from a diverging side branch.)
Modified firmware... if you have a logic board capable of driving the head logic, you can read, change, and/or erase the stored password(s). I've not seen an IDE drive that doesn't have a diag "port" on it. (it's not an actual connector, just a bunch of contact pads.)
Yes, it's intact. Of course, it's also completely useless. Any security system based entirely on a simple (predictable) username + (often guessable, and weak) password is laughable. This is only compounded by the ease of resetting the password.
"You have to use an encrypted web browser connection, so if you know that as the geeky https, you have to use an https connection, so that provides the real protection to it," Schmidt said.
I certainly hope those aren't his exact words. Otherwise, I'd have to say, he's complete f'ing idiot. SSL is not "real protection". At it's very best, it stops people from snooping. And having seen, first hand, how a number of universities manage SSL web servers, I would not be surprised in the least if they were using/allowing 48 bit SSL (which any modern computer can crack in less than a day.) HTTPS vs. HTTP didn't have a damned thing to do with this "hack".
Maybe the university would like to explain why they are using a person's SSN as a form of identification in explicit violation of the Socal Security Act of 1970. Btw, that's a serious felony that trumps the student's 4 (lame) felonies... just saying my name is [something other than my name] is a felony now? What. The. Fuck.
How about the way the idiots blindly ignore decades of ANSI SQL standards and treat char and varchar interchangably? "If any field is variable length, all fields will be [silently] changed to variable length." And they are padded with nulls, not blank spaces. The idiots truncate trailing spaces on just about every (non-blob) field type. Oh holy hell I hate such broken behavior. Make the table the way I f'ing told you to and store exactly what the fsck I handed you; how hard is that to do, really?
Rather than fuck with the rest directly (illegal), the telco throttles total available VOIP bandwidth...
And just how is this not "fuck[ing] with it directly"? Merely recognizing the traffic as VoIP (but not theirs) and rate limiting it, is directly screwing with 3rd party VoIP in violation of FCC rules (and a few laws.)
The only way they can "get away with it" is to fuck up all unclassified ("best effort") traffic. And that'll have them in court just as fast.
One thing Cringy (and you) don't seem to realize... all these 3rd party VoIP providers are already a "best effort" service. So is everything crossing the internet -- web, email, instant messages, etc. RSVP, Diffserv, et. al. are not guaranteed to work across even one hop, much less the entire internet. (and people would just abuse it if it did.)
Telco ISPs cannot partition and prioritize traffic sufficiently to screw up 3rd party VoIP without screwing up everything else in the process.
And when was this, exactly? I've ran debian woody on sparc (netra's) for about two years and, aside from the age of the packages, I have no complaints. I prefer linux much more than solaris -- esp. the abomination that is Solaris 10 (SMF... the Windows(TM) services registry comes to UNIX(tm).)
[The only good thing I can say about S10 is that Sun -- a founding member of IEEE1394 -- finally, after a decade, supports firewire for things other than their video camera.]
I beg to differ. As a sparc/linux user and kernel hacker, the linux kernel is supported on sparc (sparc64 at least, sparc32 really is some dead-end hardware.) Granted, there aren't 10,000 developers maintaining it -- there doesn't need to be -- but it is maintained. The live development kernel (bitkeeper) has been usable for a very long time on sparc. So, either you aren't using sparc/linux, you're on sparc32 hardware, or you're just very unlucky. For the record, there are many x86 users that are frequently broken, too.
The lack of a SPARC maintainer is a concern, but one that can easily be addressed. (politics aside.)
Yeah, I thought that was really f'ed up too... no read cache. what the f*** is the point of having so much memory on the card then? And let me tell you, 128M+ write-back cache is very bad idea.
You do know what's in glibc behind the sysconf calls, right? The very processing I'm bitching about. The kernel knows all this information in very efficient, simple, structures. And yet, they are not exported to userland -- and by Linus' decree, never will be. Other systems have no issues with exporting the kernel's CPU information structures -- even in NUMA configurations. (Even SCO exports this shit properly.)
This is a BS falacy. It's the reason current OSes and applications are 100,000 times larger and more complex than what came before them. If no one cares about doing anything efficiently, then nothing will be done efficiently. Just because your thumb cannot push the button on your stopwatch fast enough to measure the difference between 5 and 100 machine level operations is meaningless.
We need faster processors not to do more things, or do the same things faster, but to simply maintain the same levels of productivity because our OSes and applications are ever increasingly bloated and inefficient. We need faster processors because the code is less efficient; and we don't write efficient code because we have faster processors. This is the loop of BS we've lived with for years.
I can remember running entire "office" packages from one single sided, double density, 5.25" floppy (that's 180K, btw) -- which included the entire OS for the applications (OS-9/6809.) That was in the days when Windows came on seven (7) high density 3.5" disks (1.44M each) and office was another stack of floppies. Imagine how much more we would have time to do if programers today were like those from 10-20 years ago when every bit and every instruction mattered.
[And now for my dead horse...] For the crown jewels of lame inefficiency, look no further than the slashdot reader's beloved Linux. How does an application find out how many CPUs there are in the box? The kernel knows this milliseconds after boot and carries it around as an int it's entire life. But that simple, efficient, little number is NEVER exported to userspace. Ever. What would (minus any syscall overhead) ultimately be one mov instruction to give something the kernel has always known to userland turns into literally THOUSANDS of instructions both in userland and the kernel to generate and process all the (arch dependant) human formated ASCII text of/proc/cpuinfo.
The point extends to just about everything in/proc... look at all the waste of coverting things to ASCII for humans to read (which, btw, is usually not read by humans), converting them back to binary, to then convert them back to ASCII to show to a human.
You mis-read the comment. (and again, know little about wiki's setup) The point is, there aren't any Microsoft Windows boxes in the cluster. And I don't expect the Wikimedia Foundation to approve the cash outlay for buying windows and mssql licenses for the number of system currently serving as database engines. Plus there's the complexity of those boxes not just being db servers, and the fact that none of the admins are anywhere near the actual hardware -- remote management of windows boxes is not something I would recommend (and not something easily done via ssh.)
MySQL is not inferior in all possible characteristics... MSSQL is a windows only product. I cannot run it on Solaris, OS X, AIX, Tru64, linux, etc. It, thus, loses on that characteristic. Wiki is not a windows shop, so stop wasting your time suggesting a windows product. The cluster is running linux. Bring linux software to the table and we'll talk. Wiki uses mysql because it's free and it's fast. My suggestion would be Oracle, but it's most certainly not cheap or free.
A word on breakers... first, they aren't fuses. They are magnetically thrown -- pull too much current through it and an electromechanical break is closed releasing the breaker contacts which are pushed/pulled apart by springs. As it's magnetically thrown, tripping one breaker can (and does) trip surrounding breakers. I've seen it happen a number of times -- with brand new breakers, even.
FYI: the replica's were powered down too. It takes time to verify integrity of dozens of servers -- and until you do, you don't know for sure that nothing is borked. Oh and I guess to missed the part about the binlog filling up (stopping replication) and the db continuing on (breaking replication.)
I would never donate to this goddamn Wikipedia project as long as I know that the funds are going to end up being sapped to support their crippled shitball database.
Technically, your donation wouldn't be. The donations are used to pay for things like new servers, bandwidth, co-lo costs, etc. As far as I'm aware, the project hasn't bought any software -- which means MySQL AB hasn't been paid for the "crippled shitball database" being used. (And bomis may still be picking up the bill for the bandwidth and co-lo space.) All of the people working on the project are volunteers; they aren't paid for their contributions.
Things like this can happen to any database. Anyone who will claim otherwise doesn't have the experience to be making such a claim. Corruption is possible with any database.
MSSQL? You're joking, right? If you knew anything about wikipedia, you'd know how laughable that suggestion is. Oracle would be nice, but I'm not sure they'd hand over a license for free -- and oracle is certainly not a hands-free db engine.
Pulling the power to a database server can result in lost data and damage to the data files. Some databases are more resilient than others, but corruption can occur in just about any database. Sybase (various versions) will refuse to start a db that was not shutdown correctly -- you either have to force start the db or check it first, even when there's a transaction log. I've personally seen postgres databases permanently corrupted by a power outage [the power supply blew up, fwiw.] Even Oracle isn't immune to backhoe's, however corruption is pretty rare *grin*.
Battery backed hardware RAID is good insurance, but "these things happen." And with the db traffic volumes of wikipeida, it's much more likely to happen because data is constantly being written to disk. The choice of db engine really doesn't make a huge difference.
An analog modem will take more than "a couple of seconds" to train. I just timed it... it took 23sec from the time the modem went off-hook to "CONNECT". Add a few (~3) seconds to login and you're very nearly a half minute. That's a long time to wait -- twice the default DNS timeout of 15s. And that's with a digital phone line -- any noise or faults on your POTS line will add to the training time.
You don't know how ISDN works do you? You don't push data over the D channel. I've not seen any telco's that don't change per packet for data over the D channel. Or per-packet for packet switched calls -- assuming they'll even do packet switched calls at all. [Bellsouth won't.]
ISDN is just like POTS, just with different hardware. You still have to dial in just the same. The process takes a few seconds instead of minutes, but it's still dialup. 128k is done via multi-link PPP, which has to be supported by your ISP and your local hardware/software. And ISDN is far more complex than DSL/cablemodem/POTS -- there's no "plug it in and it works."
[Disclaimer: I've been around ISDN for a decade. It was my connectivity solution for 7+ years. I use a cablemodem now... 1/4th the cost and ~70x faster.]
Slashdot Mirror
Go find a copy of Source Off-Site. Then you can hit VSS crap from just about anywhere. Yeap, it sucks as much as you'd think it would... crap ontop of crap is just a bigger pile of ...
I even tried using SS.EXE under linux (with a sutable emulator.) Just don't use VSS. Even CVS is better -- and that's just sad.
More accurately: BitMover loses all of it's advertising.
Seriously, have you ever head of BitKeeper outside of Linux discussions? Have you ever seen an ad for BitKeeper anywhere? Even if the quoted figures are right ($500,000/year), that's pretty cheap advertising for the amount of coverage.
(I've known about BK/BitMover for a long time simply because I know of Larry McVoy. But aside from that association, I've never heard of either.)
There is absolutely zero requirement for anyone to use bitkeeper. It's easier for Linus to bk pull from someone's tree but there was never a requirement made of anyone to do it that way. Plus, the main tree is only writable by Linus (and maybe a few others), so one cannot bk push their changes into the main tree anyway. (They still have to be sent as a patch or pulled by Linus.)
So, I'll say it again:
- There should have been an organized effort at creating an OSS project that would work as well (or, preferably better) than BK. If there wasn't an OSS tool that was the best choice, one should have been developed.
That's just it. The OSS world never creates one wheel, and rarely finishes one before embarking on the next.Linus chose BK because it was the only thing available at the time to do what was needed. It's not about one being better than another. It comes down to meeting a set of criteria. Several years (and a lot of bitching) later and we're still at the same spot... there still aren't any OSS projects to meet all of the requirements. BK/Free has been around for 5 years; Linus has been using it for 3 years, so where's all the alternatives from those that have been bitching constantly against the use of BK? Well? I'm f***ing waiting. If you don't have something that'll do the job, then you should shutup and let me use what ever'll do the job. That's the thing the opponents refuse to accept. ("I don't need to invent a wheel; Larry has kindly give me one of his.")
Both -- as they are the same thing. BK brings conciderable productivity to the process. No open source tools provide anything close to what BK is doing. Linus knows this already, but he's been left no choice. ('tho, through no fault of his own.)
Any SCM would help vs. the decade old process of patch and manually resovle the conflicts -- and there are always conflicts. This is simply because it forces a common ancestry in every development arm. diff and patch don't carry any history or version graphs. BK takes this a little too far, IMO, by hanging everything off change sets -- a single change suddenly is dependant on every change in every file that comes before it. (This is good for commercial development as every tree is supposed to be the same. However, for the linux kernel, there are too many side branches with changes unfit for the main branch that prevent easy patch integration -- main can never pull patches from a diverging side branch.)
Modified firmware... if you have a logic board capable of driving the head logic, you can read, change, and/or erase the stored password(s). I've not seen an IDE drive that doesn't have a diag "port" on it. (it's not an actual connector, just a bunch of contact pads.)
Yes, it's intact. Of course, it's also completely useless. Any security system based entirely on a simple (predictable) username + (often guessable, and weak) password is laughable. This is only compounded by the ease of resetting the password.
- "You have to use an encrypted web browser connection, so if you know that as the geeky https, you have to use an https connection, so that provides the real protection to it," Schmidt said.
I certainly hope those aren't his exact words. Otherwise, I'd have to say, he's complete f'ing idiot. SSL is not "real protection". At it's very best, it stops people from snooping. And having seen, first hand, how a number of universities manage SSL web servers, I would not be surprised in the least if they were using/allowing 48 bit SSL (which any modern computer can crack in less than a day.) HTTPS vs. HTTP didn't have a damned thing to do with this "hack".Maybe the university would like to explain why they are using a person's SSN as a form of identification in explicit violation of the Socal Security Act of 1970. Btw, that's a serious felony that trumps the student's 4 (lame) felonies... just saying my name is [something other than my name] is a felony now? What. The. Fuck.
How about the way the idiots blindly ignore decades of ANSI SQL standards and treat char and varchar interchangably? "If any field is variable length, all fields will be [silently] changed to variable length." And they are padded with nulls, not blank spaces. The idiots truncate trailing spaces on just about every (non-blob) field type. Oh holy hell I hate such broken behavior. Make the table the way I f'ing told you to and store exactly what the fsck I handed you; how hard is that to do, really?
- Rather than fuck with the rest directly (illegal), the telco throttles total available VOIP bandwidth...
And just how is this not "fuck[ing] with it directly"? Merely recognizing the traffic as VoIP (but not theirs) and rate limiting it, is directly screwing with 3rd party VoIP in violation of FCC rules (and a few laws.)The only way they can "get away with it" is to fuck up all unclassified ("best effort") traffic. And that'll have them in court just as fast.
One thing Cringy (and you) don't seem to realize... all these 3rd party VoIP providers are already a "best effort" service. So is everything crossing the internet -- web, email, instant messages, etc. RSVP, Diffserv, et. al. are not guaranteed to work across even one hop, much less the entire internet. (and people would just abuse it if it did.)
Telco ISPs cannot partition and prioritize traffic sufficiently to screw up 3rd party VoIP without screwing up everything else in the process.
And when was this, exactly? I've ran debian woody on sparc (netra's) for about two years and, aside from the age of the packages, I have no complaints. I prefer linux much more than solaris -- esp. the abomination that is Solaris 10 (SMF... the Windows(TM) services registry comes to UNIX(tm).)
[The only good thing I can say about S10 is that Sun -- a founding member of IEEE1394 -- finally, after a decade, supports firewire for things other than their video camera.]
I beg to differ. As a sparc/linux user and kernel hacker, the linux kernel is supported on sparc (sparc64 at least, sparc32 really is some dead-end hardware.) Granted, there aren't 10,000 developers maintaining it -- there doesn't need to be -- but it is maintained. The live development kernel (bitkeeper) has been usable for a very long time on sparc. So, either you aren't using sparc/linux, you're on sparc32 hardware, or you're just very unlucky. For the record, there are many x86 users that are frequently broken, too.
The lack of a SPARC maintainer is a concern, but one that can easily be addressed. (politics aside.)
Yeah, I thought that was really f'ed up too... no read cache. what the f*** is the point of having so much memory on the card then? And let me tell you, 128M+ write-back cache is very bad idea.
You do know what's in glibc behind the sysconf calls, right? The very processing I'm bitching about. The kernel knows all this information in very efficient, simple, structures. And yet, they are not exported to userland -- and by Linus' decree, never will be. Other systems have no issues with exporting the kernel's CPU information structures -- even in NUMA configurations. (Even SCO exports this shit properly.)
This is a BS falacy. It's the reason current OSes and applications are 100,000 times larger and more complex than what came before them. If no one cares about doing anything efficiently, then nothing will be done efficiently. Just because your thumb cannot push the button on your stopwatch fast enough to measure the difference between 5 and 100 machine level operations is meaningless.
/proc/cpuinfo.
/proc... look at all the waste of coverting things to ASCII for humans to read (which, btw, is usually not read by humans), converting them back to binary, to then convert them back to ASCII to show to a human.
We need faster processors not to do more things, or do the same things faster, but to simply maintain the same levels of productivity because our OSes and applications are ever increasingly bloated and inefficient. We need faster processors because the code is less efficient; and we don't write efficient code because we have faster processors. This is the loop of BS we've lived with for years.
I can remember running entire "office" packages from one single sided, double density, 5.25" floppy (that's 180K, btw) -- which included the entire OS for the applications (OS-9/6809.) That was in the days when Windows came on seven (7) high density 3.5" disks (1.44M each) and office was another stack of floppies. Imagine how much more we would have time to do if programers today were like those from 10-20 years ago when every bit and every instruction mattered.
[And now for my dead horse...]
For the crown jewels of lame inefficiency, look no further than the slashdot reader's beloved Linux. How does an application find out how many CPUs there are in the box? The kernel knows this milliseconds after boot and carries it around as an int it's entire life. But that simple, efficient, little number is NEVER exported to userspace. Ever. What would (minus any syscall overhead) ultimately be one mov instruction to give something the kernel has always known to userland turns into literally THOUSANDS of instructions both in userland and the kernel to generate and process all the (arch dependant) human formated ASCII text of
The point extends to just about everything in
You mis-read the comment. (and again, know little about wiki's setup) The point is, there aren't any Microsoft Windows boxes in the cluster. And I don't expect the Wikimedia Foundation to approve the cash outlay for buying windows and mssql licenses for the number of system currently serving as database engines. Plus there's the complexity of those boxes not just being db servers, and the fact that none of the admins are anywhere near the actual hardware -- remote management of windows boxes is not something I would recommend (and not something easily done via ssh.)
MySQL is not inferior in all possible characteristics... MSSQL is a windows only product. I cannot run it on Solaris, OS X, AIX, Tru64, linux, etc. It, thus, loses on that characteristic. Wiki is not a windows shop, so stop wasting your time suggesting a windows product. The cluster is running linux. Bring linux software to the table and we'll talk. Wiki uses mysql because it's free and it's fast. My suggestion would be Oracle, but it's most certainly not cheap or free.
A word on breakers... first, they aren't fuses. They are magnetically thrown -- pull too much current through it and an electromechanical break is closed releasing the breaker contacts which are pushed/pulled apart by springs. As it's magnetically thrown, tripping one breaker can (and does) trip surrounding breakers. I've seen it happen a number of times -- with brand new breakers, even.
FYI: the replica's were powered down too. It takes time to verify integrity of dozens of servers -- and until you do, you don't know for sure that nothing is borked. Oh and I guess to missed the part about the binlog filling up (stopping replication) and the db continuing on (breaking replication.)
- I would never donate to this goddamn Wikipedia project as long as I know that the funds are going to end up being sapped to support their crippled shitball database.
Technically, your donation wouldn't be. The donations are used to pay for things like new servers, bandwidth, co-lo costs, etc. As far as I'm aware, the project hasn't bought any software -- which means MySQL AB hasn't been paid for the "crippled shitball database" being used. (And bomis may still be picking up the bill for the bandwidth and co-lo space.) All of the people working on the project are volunteers; they aren't paid for their contributions.Things like this can happen to any database. Anyone who will claim otherwise doesn't have the experience to be making such a claim. Corruption is possible with any database.
MSSQL? You're joking, right? If you knew anything about wikipedia, you'd know how laughable that suggestion is. Oracle would be nice, but I'm not sure they'd hand over a license for free -- and oracle is certainly not a hands-free db engine.
Pulling the power to a database server can result in lost data and damage to the data files. Some databases are more resilient than others, but corruption can occur in just about any database. Sybase (various versions) will refuse to start a db that was not shutdown correctly -- you either have to force start the db or check it first, even when there's a transaction log. I've personally seen postgres databases permanently corrupted by a power outage [the power supply blew up, fwiw.] Even Oracle isn't immune to backhoe's, however corruption is pretty rare *grin*.
Battery backed hardware RAID is good insurance, but "these things happen." And with the db traffic volumes of wikipeida, it's much more likely to happen because data is constantly being written to disk. The choice of db engine really doesn't make a huge difference.
An analog modem will take more than "a couple of seconds" to train. I just timed it... it took 23sec from the time the modem went off-hook to "CONNECT". Add a few (~3) seconds to login and you're very nearly a half minute. That's a long time to wait -- twice the default DNS timeout of 15s. And that's with a digital phone line -- any noise or faults on your POTS line will add to the training time.
(The same call via ISDN took *3* seconds)
You don't know how ISDN works do you? You don't push data over the D channel. I've not seen any telco's that don't change per packet for data over the D channel. Or per-packet for packet switched calls -- assuming they'll even do packet switched calls at all. [Bellsouth won't.]
ISDN is just like POTS, just with different hardware. You still have to dial in just the same. The process takes a few seconds instead of minutes, but it's still dialup. 128k is done via multi-link PPP, which has to be supported by your ISP and your local hardware/software. And ISDN is far more complex than DSL/cablemodem/POTS -- there's no "plug it in and it works."
[Disclaimer: I've been around ISDN for a decade. It was my connectivity solution for 7+ years. I use a cablemodem now... 1/4th the cost and ~70x faster.]
One word: IDSL (range: 50k+ ft.) [it's basically ISDN with all the signalling removed.]