Why does everyone keep speaking about EXT4 as if it's broken? It's working exactly as designed. It's the applications that need fixing, no?
Everyone expects filesystem to behave transactionally these days, so that if you follow the create-write-rename pattern that you either get the old contents or the new contents of the file. I just wrote this diatribe on the ubuntu bug report:
"You can opine all you want, but the problem is that POSIX does not specify anything..."
I'll opine that POSIX needs to be updated.
The use of the create-new-file-write-rename design pattern is pervasive and expected that after a crash either the new contents or the old contents of the file will be found there, but zero length is unacceptable. This is the behavior that we saw with ext2 where the metadata and data writes could get re-ordered and result in zero-length files. With the 800 servers that I was maintaining then, it meant that the perl scripts for our account management software would zero-length out/etc/passwd, along with other corruption often enough that we were rebuilding servers every week or two. As the site grew and roles and responsibilites grew that meant that with 30,000 linux boxes, even with 1,000-day uptimes there were 30 server crashes per day ( even without crappy graphics drivers, a linux server busy doing apache and a bunch of mixed network/cpu/disk-io seems to have about this average uptime -- i'm not unhappy with this, but at large numbers of servers, then server crashes catch up with you ). And while I've never seen this result in data loss, it does result in churn in rebuilding and reimaging servers. It could also cause issues where a server is placed back into rotation looking like it is working (nothing so obvious as/etc/passwd corrupted), but is still failing on something critical after a reboot. You can jump through intellectual hoops about how servers shouldn't be put back into rotation without validation, but even at the small site that I'm at now with 2,000 servers and about 300 different kinds of servers, we don't have good validation, don't have the resources to build it, and rely on servers being able to be put back into rotation after they reboot without worrying about subtle corruption issues.
There is now an expectation that filesystems have transactional behavior. Deal with it. If it isn't explicitly part of POSIX then POSIX needs to be updated in order to reflect the actual realities of how people are using Unix-like systems these days -- POSIX was not handed down from God to Linus on the Mount. It can and should be amended. And this should not damage the performance benefits of doing delayed writes. Just because you have to be consistent doesn't mean that you have to start doing fsync()s for me all the time. If I don't explictly call fsync()/fdatasync() you can hold the writes in memory for 30 minutes and abusively punish me for not doing that explicitly myself. But just delay *both* the data and metadata writes so that I either get the full "transaction" or I don't. And stop whining about how people don't know how to use your precious filesystem.
It's actually quite a geeky activity. Although being unfit makes decompression sickness more likely, it's not an activity that requires much in the way of physical prowess. There's maths in those dive tables, or if you prefer gadgets there's dive computers. Not that there's not plenty of gadgetry involved in the breathing apparatus side of things.
It goes a lot beyond that as well, when you get into technical and cave diving.
I'm continually drawing parallels between my experiences at Amazon managing 30,000 servers, and cave diving in terms of the philosophies that are successful. You can't be successful managing that many servers if they are all unique, there has to be standards and there has to be uniform reactions among the operational staff for any emergencies to reduce MTTR. Underwater it takes on an additional urgency since your reactions to emergencies involve lack of breathing gas and your "MTTR" needs to be in seconds. There's also principles of failure analysis and single points of failure which cross over fairly easily. There's also more nebulous principles such as resisting the urge to solve problems in advance of actually encountering them -- which draws me towards Agile simply for the You Aint Gonna Need It - YAGNI principle - for reducing the complexity of designs. And the law of unintended consequences applies in both disciplines -- trying to fix a problem you don't actually have can cause problems elsewhere.
That's not even getting into the way that some people get geeky about being underwater. There's a whole different set of wildlife down there to get geeky about, and most divers love to find some new animal underwater and figure out what it was they saw online by consulting other geeks who can ID the critter. When cave diving there's a whole different set of geekery involved in the environment of the cave that I don't even know a tiny fraction of so far. And with wrecks, there's the whole history of the wrecks, as well as the geekery involved in going out and doing the historical research and side scanning and finding new wrecks.
Diving really has a nearly unlimited ceiling on how geeky you can get about it.
Spend any time at 40m, and just make sure you know what you're doing; deco stops come into play very quickly.
40m/130ft is actually a baby technical dive. Its easy to do an hour-long dive on wrecks at that depth and do only very minimal O2 deco with minimal risk.
I got interested in technical diving after having done a day where we did 2 recreational 30-minute dives to 30m and got narc'd, while the technical divers on the boat both did 2 60-minute dives using helium to reduce narcosis and penetrated the entire length of both wrecks that we dove on. I've since gone back there and done both of those dives again as technical dives, and added scooters so that we spent a bunch of time zooming around a viewing the entire outside of the wrecks. Very fun dives.
60m/200ft is a whole different ballgame, and 90m/300ft is yet another ballgame, entirely.
There was a Japanese sub that sank off the coast of Hawaii that people dove. It was in about 140 feet of water, but the top deck was at 110 feet. Remember, unless your suicidal or stupid (or working for the Discovery Channel), you don't actually go under or into the wreck; you just go near it and around it. For PADI, wreck dives are one of their advanced courses.
Or unless you're simply certified to penetrate the wreck, and ideally this includes both courses taken on wreck penetration (and cave diving), along with more long-term mentoring with other experienced wreck divers.
It may be a little crazy, but I think that people who jump out of perfectly working airplanes for fun, or like to climb up sheer rock faces are absolutely nuts. Wreck diving (and cave diving) are far from suicidal if you just get the training, experience, mentoring and follow some basic rules.
Artificial reefs are also very useful for wreck diving n00bs. As a n00b, myself, so far I've only got 24 cave dives under my belt, and two wreck penetration dives on the Saskatchewan and Cape Breton up in Nanaimo, British Columbia (artificial wrecks). The newly sunk artificial reefs are somewhat safer for newbie wreck divers since they have been 'cleaned up' and have less crap that you're going to get caught on, so that less experienced wreck divers can get experience executing dives in an overhead environment with less crap inside the space, no wires hanging down waiting to grab ahold of scuba gear, etc. Although given the fatality on the Cape Breton and the triple-fatality on an artificial wreck in Florida fairly recently it is not without risks (both of those incidents involved violation of training standards).
I also don't believe the PADI wreck diver certification trains a diver to enter wrecks. It is about diving on wrecks rather than in them. You have to go to do a different (technical) dive training agency in order to get trained to dive inside wrecks.
Re:Well, we ought to get proof of the sunspot theo
on
The Quietest Sun
·
· Score: 1
I'm not basing this on computer models, I'm basing it on observation. For a million years and multiple ice age cycles there has been correlation between changes in solar insolation due to changes in the orbital parameters of the Earth (modulo a couple supervolanoes, etc). This correlation also establishes an upper bound on the intrinsic variability of the Sun's output over the past million years since if you increase the intrinsic variability of the Sun enough you would destroy the correlation between the Earth's orbital parameters and the Ice Ages. That is experimental evidence, not computer models, and has nothing whatsoever to do with CDO valuation models.
So we can state that the effect you suggest of having the Sun dim enough to cause an Ice Age, has not been a factor in climate change for the past million years.
We also have experimental evidence which shows a decline in temperature of about 0.2C due to the Maunder Minimum when sunspot activity went away. That sets a reasonable bound on what to expect from solar variability.
So, unless you have some evidence of a fundamental change in the way the Sun has worked for the past million years, I'm heavily betting that the worst that could happen is a new Maunder Minimum with a decrease of about 0.2C, and what is vastly more likely is that the new sunspot cycle is going to start soon and all this will blow over.
And just because Outliers can happen doesn't mean that you get to make up whatever you want. The collapse of CDOs and their valuation models was foreseable (I've been in cash since 2004 and warren buffet saw this trainwreck coming), because it was obvious that their statistical basis was fundamentally flawed and that they had no way to price in a bad recession. There's no similar obvious flaw in solar models or our historical understanding of solar output.
And the fundamental mistake that was made in the financial sphere by everyone (once again) was assuming that "this time it is different". That mentality is behind every single financial bubble going back for as long as there are records. And arguing that we're suddenly going to enter an Ice Age due to some kind of solar minimum is "this time it is different" mentality. Not only are you assuming that this solar cycle will deviate from the pattern over the past several hundred years, but will exceed the pattern over a few thousand years and create a once-in-a-million years event, pluging the world into an Ice Age. Typically it doesn't work that, patterns and cycles tend to repeat. My money is on a mostly normal new solar cycle.
Re:Well, we ought to get proof of the sunspot theo
on
The Quietest Sun
·
· Score: 1
No it wouldn't lead to an ice age.
Another Maunder Minimum elimination of sunspot activity might cool the climate by about -0.2C which would unwind 2 decades of global warming and get us back to the 80s or so. Solar cycles, however, are not important in generating ice ages, the ice ages are triggered by the Milkankovich cycles -- which is ultimately solar in nature but the variability is due to changes in the Earth's orbital parameters and not changes in solar output.
ENSO cycles are more significant than Solar Cycles
on
The Quietest Sun
·
· Score: 1
El Nino cycles in the pacific ocean are more important than the solar cycle:
"But half the companies out there aren't actually doing anything complicated."
Well, I'm responding to a very strong statement saying that cloud computing will "make centralized IT go away". And while it may do so for small business, which needs a couple dozen servers to run some "web 2.0" apps or a storefront or whatever, I doubt it will have much of an impact on the IT staffs at S&P 500 companies.
If you look closely at Amazon's SLAs as well, they aren't going to be acceptable to most large companies. Financial institutions might be able to outsource some offline batch analysis and model crunching to EC2, but their online transactional processing that needs just stupid reliability isn't going to be transferable to Amazon's cloud.
You are correct though that by sheer number, most companies are small and most companies don't have very complicated IT needs. However, "cloud computing will make centralied IT go away" is just silly if you've got a background at centralized IT at large companies.
There will still be a lot of IT out there, it may just be bigger IT, and some of the small IT may be eliminated, or it may turn contract work.
Cloud computing doesn't make centralized IT go away.
Amazon EC2 only provides you with servers. You still need system admins to configure and run and debug the boxes if you're doing anything remotely complicated.
It does solve provisioning issues, procurement issues and lights-out management. But that is just a sliver of centralized IT.
And having Amazon provide "remote hands" for you to replace failed hardware is not even a "centralized" part of IT. Even without cloud computing you shouldn't have your IT organization tightly coupled to where your sites are. All that you need is the occasional physical hardware replacement, and management of the facilities (power, cooling, etc).
Actually, the obvious way to prevent against DNS attacks on the authentication server is to have the user's client have already setup trust to the authentication server when the identity was initially setup. Then the client would cryptographically check to see that the authentication server the website was trying to use was the trusted one. There would still be attacks possible via impersonating the website itself, but those risks currently exist as well. This approach also could be useful to fix phishing attacks. If you only allow this kind of authentication to a given website and the client webserver does no kind of fallback to password auth, then the phishing site cannot gather any passwords, and if they try to proxy to the authentication server all they get is a challenge/response authentication which is useless to gain access to the site they are trying to exploit. So you could successfully login to a phishing site without giving them anything in that process. They'd need to then trick you into giving further access to credit card data, etc.
The nice thing about this approach is that I can run my own authentication server on my own domain in the machine's in my home just like I currently run my own website and sendmail instance. Then the passwords are entirely stored and managed on machines under my own control and I can setup policy about which websites I trust and how much I trust them.
For less astute internet users, their ISPs could setup authentication servers, just like their ISPs setup sendmail and DNS for them.
Although, looking through the OpenID spec it seems fairly blog-centric and it reads like someone's first attempt at writing an RFC...
The security win here clearly goes to OpenID. With OpenID you only have one password to manage and remember which means you can use good password management practices and rotate/change your passwords on a frequent basis. If it does challenge/response authentication correctly you should also be able to make sure that attackers that 0wn the website you are visiting cannot use your credentials to attack your accounts on other sites. I haven't looked that the OpenID spec for more that 5 seconds, so I don't know how it works, but the correct way to do this is for the intermediate site to proxy a challenge/response authentication session to the OpenID authentication server and then to get a response back indicating if it succeeded or not. The big security hole here will be that the intermediate website you are trying to authenticate against will need to securely be able to contact the authentication server. The obvious attack is against the DNS entry of the authentication server to point it to a fake one which always returns that authentication succeeds. I'm not sure if OpenID has thought of a way around this or not yet.
I had a similar idea several years ago, but I would have implemented it by extending DNS using another record like an MX record so that people could use their e-mail addresses as IDs which would lookup an authentication server based on the DNS zone record, and would then contact that server to do challenge/response authentication. This sounds like the same kind of thing only adding the web and URIs on top of it.
...I mean the skills summary is a bit silly, but that is probably an artifact of the database that the listing is in, and that the submitter wanted a wide audience of potential applicants.
What they're looking for is a bilingual windows drone sysadmin to take care of their machines. Speaking from experience looking through resumes, there are a way too many mediocre or sub-mediocre system admins out there looking for a job (and I look thorugh unix resumes -- I've heard the windows ones are worse). Paying them $40k -- even CDN -- is probably being generous.
Most system admins are bad at what they do. I don't know why anyone would think they should all get paid $80k a year...
If you aren't a bad system admin, then you should realize that the $40k job listings are communicating to you that those aren't the jobs for you. If you had the job, in addition to being underpaid, you'd probably be unchallenged and bored.
When you have a thousand machines, if you're constantly losing filesystems then you spend way too much SA time rebuilding them.
of course if you've got a cluster of 100 machines that are all doing the same things and you can even make the app go 5% faster by a different filesystem, that can be a saving of $20,000 or so.
Except for the fact that the "Insulin" thinking is false. See this article:
http://venus.nildram.co.uk/veganmc/insulin.htm
I don't think this did anything to debunk the "insulin thinking". In fact this data might explain why I had more success losing weight when I was eating apples than when I've been eating grapes. I hope the authors publish more data on more foods for this index.
Basically, one of the points made is that it takes a lot of exercise to lose weight.
This was one of the reasons why I did not like the information in "The Hackers Diet". The author completely ignored the fact that the major benefit of excersize is *not* how many calories you burn during the excersize, but how much it increases your metabolism. Excersize is more important to weight loss than he makes out.
He also ignored the effect that highly glycemic foods that spike insulin levels have on your hunger levels and your food consumption. He argued that you should reduce calorie consumption, but gave no suggestions other than calorie counting on how to achieve this.
While I agree with your recommendations about diet I do tend to disagree with this:
Regarding the carbs fiasco - I guarantee you, if I eat 1 pound of carbs, and you eat 1 pound of fat, you will put on twice the weight as you consume (more than) twice the calories.
I've been following a low-glycemic diet similar to what you suggest (balanced diet low in simple carbs, low fat and low cal). I've found that when I cheat by eating red meats (and I can still pack away an awful lot of calories -- particularly with kosher dogs) then I don't gain weight -- although I don't lose weight either. The problems that I have are when I start to eat white breads (the hot dog buns) and then I start to gain weight.
My experience tends to suggest that its not merely calorie intake, similar to what the Atkins people claim.
I find the carbohydrates vs. fats arguments silly. It's all about calories. It's simple: If you take in more than you burn per day, no matter what the source, you gain weight.
Sorry to disagree, but I've been doing a low-glycemic diet for the past 6 months and haven't found this to be true. For the diet that I'm on I try to stick to a low-fat, low-glycemic, low-calorie diet in order to lose weight. I've found that I can occasionally gorge on high-fat high calorie foods like hot dogs and steak and while I stop losing weight I don't tend to gain weight. The problem that I have which causes me to gain a few more pounds is when I start cheating on the white bread. Then I usually put a few pounds back on and find myself feeling "addicted to carbs" and have to go through withdrawal again and get back on track to losing weight.
I believe the biochemical mechanism behind this might be that the problem is insulin levels. For example, there have been studies that rats don't gain weight when whey they have the insulin receptors on their fat cells mutated so that insulin won't bind to them. Similarly I find that I gain weight when my insulin levels are high and not simply when my calorie intake is high.
I've lost 25 lbs this year through following a diet based on the glycemic index. It is based on eating an FDA recommended amount of carbs but sticking to low-glycemic foods like fruits (primarily) and whole wheats and staying away from the white bread and potatoes. I've also had the most success with the diet when I'm also low-calorie and low-fat at the same time as being low-glycemic. When I can't maintain all three (usually through eating too much fatty red meat) I tend to just keep my weight constant, but when I start cheating on the high-GI carbs I wind up putting a few pounds back on.
Anyway, I've found Atkins to be overly-simplistic and I've successfully lost weight through a diet which according to the Atkins people you can't lose weight on. At the same time I'm not putting my health at risk through eating too much bad fat or through the effects of ketogenic diets (and my breath doesn't smell).
Also, you get the same benefits: higher HDL, lower LDL, reduction/elimination of type II diabetes risk and reduced blood sugar volatility. And I've got a more varied diet (my diet is a super-set of the Atkins diet) and is more sustainable over the long term.
It also makes a lot more sense anthropologically. Humans have been able to not gain weight off of both high fat animal product diets *and* low fat high carb diets, but it has been since we've gotten such a highly glycemic diet that the obesity epidemic in industrialized countries has exploded (and its worst in the US where high fructose corn syrup is added to *everything*).
This is exactly the sort of meaningless wank that got thousands of windows loving, unix illiterate fucktards worldwide 'interested' in CS/IT/etc shit. Now they're whining that they're not getting the 100k pa they used to for their shithouse vb/asp/etc job (if they're lucky enough to have a job, not that tech jobs are anything but boring). In summary, LOL eat shit.
No, actually, you don't get it.
In order to survive in the IT industry in the US you're going to have to be able to be both literate in Unix and be able to do all the technical heavy lifting, and you're going to have to be able to do all that "meaningless wank." All of that "meaningless wank" isn't meaningless when you've got a department of technically capable people who are drowning under the workload of tickets, pages and box build-outs and have no idea how to make their life better. In that circumstance you need to be able to understand how to fix an IT department to make it run better in addition to be able to fix computers to make them run better. If you can't do that, you won't be the one surviving, you'll be the one that your management will get fed up with and fire or outsource you eventually to someone who has found a clue. The gravy train that you've got from being the insufferable unix guru with attitude is going to dry up. Your making it a virtue to ignore anything related to running a business as being "meaningless wank" is what is going to get you canned, and I'm going to laugh...
Is IT still a viable field to get into and if so will it last?
Yes. But in the future it won't be enough to merely understand how computers work in order to make it in the IT field. You will need to understand how an IT department fits within the overall structure of an organization and how to meet the requirements of your internal customers. You will also need to understand how to scale your IT services within the organization. There are entirely too many bad system administrators out there who really need to get either educated or purged, and even the current IT downswing hasn't been able to do it. There are still too many people who are in the IT job market who should simply stop sending their resumes around. 1999 is over, and you weren't that good.
If you can't think beyond "this machine is broken, here's how to fix it" to "this process is broken, here's how to fix it" then don't bother going into IT. There are already way too many people who are perfectly technically capable in IT but who have no idea of how to solve, or in some cases even identify, a larger problem.
Since microsoft has made all their money from stock option accounting fraud and taking money from investors, its amusing that they're finally being forced to give a few pennies back. If this trend continues, and microsoft burns through their cash holdings by paying out dividends they might at some point realize that the company is broke.
Of course if the economy, the stock market, and their stock value starts to increase again, then they can still keep the pyramid scam going.
Don't believe me? Here's how it works: Microsoft prints up some new employee stock options. Those employees eventually buy their stock options and give the money to microsoft. Microsoft pockets that money and reports it as *earnings* instead of an expense. That money then goes into their statement as profits and cash.
This is no different from a company which continuously offers new stock for sale every year. But in that case you would never consider that sale of stock to be profit. It is a way of raising money, just like a company going IPO to raise money. But it doesn't reflect on the health of the company and eventually the company can burn through it all. In fact, these kinds of liquidity events should drive the stock price down since you're issuing more stock and diluting the other holdings.
In the case of Microsoft, though, these rules do not apply. In fact since microsoft reports all this cash as earnings then it looks like Microsoft is unreasonably profitable. They then can support really, really silly market capitalizations which pushes their stock price up -- this causes people to invest in them, and causes them to be a major holding of index mutual funds. Then the whole cycle continues...
...until now. Now they've got to start burning through their cash by issuing dividends in the hope that their stock price will recover. And it might, and they may be able to continue with the pyramid scam. But on the other hand they may run out of money to issue dividends with and the entire scam may finally collapse...
What you don't see as much of in Solaris is patches in a stable kernel which are necessary, but yet break functionality. Of course you still have to patch, but in general you get a system image which is more widely applicable across all of your machines.
Contrast this to linux where you have to mantain 3-5 different kernel versions at a minimum. And certifying a kernel version is a lengthly process, with no assurances that the issues you've had in previous kernels have been addressed or that there will be no new issues which are added (in fact, it seems like you can count on later kernels breaking something which was previously stable).
To use this silly metaphor, some puppies are fairly low maintenance and some get diarrhea on the carpet..
Anyways, open source is winning and will win more because it can innovate faster and for less. It is not just "great for innovation", it costs less, and costs (TCO) keep going down.
The problem is that the people who are writing the open source code do not understand how to keep TCO costs down. The open source community is by-and-large a community of software developers who don't want to be burdened by the issues they had working for corporations. A prime example of this is the open source "release early, release often" mantra which is practically hostile to any use of open source products in the Enterprise market (which is the only market that really cares about TCO). If you release early and often you continue to introduce bugs and you never stabilize a release (and I spend a lot of time in my job dealing with 2.4.x kernels in an enterprise environment, and it is *not* a stable kernel branch -- no matter what people might think based on their limited experience with a handful of Linux boxes that they admin). By releasing early and often you also produce conniption fits with third party vendors, who need a lead time to QA test their products on the stable release and who expect the release they're targetting to be supported.
If open source software is going to compete with commercial unix products, the open source development community is going to need to grow up. They're going to need to start releasing code which becomes progressively more stable, which is more thorughly QA'd and regression tested, and which has a better development model.
I don't know if this can happen. It really requires the presence of people who have a substantial amount of control and who are getting paid to do jobs like program management that people normally don't do for free. It might happen if RedHat or IBM or another big player (or consortium of players) officially forks the Linux kernel. I don't see any way of it happening given the current development model (within the Linux kernel at any rate).
FreeBSD gives me a little bit of hope. At least the FreeBSD community seems to understand that they're not writing the code *just* for themselves and that they have a userbase that would like their code to run on servers in a stable fashion. The Linux community seems to largely be self-masturbatory developers who just want it to run faster, and don't care if their end users are getting paged at 2AM in the morning due to panics in the supposedly-stable kernel series.
Linux is not a puppy. I ran Redhat 6.2 for my firewall until just like a month ago. Linux doesn't have to be upgraded and tendered to. Maybe for exploits but Solaris has those too.
Try running 1000+ Linux boxes with hundreds of different workloads and configurations (something more difficult than just stamping out a 100 identical machines in a beowulf cluster). Come back to me and tell me that Linux is better than commercial unixes for management in the enterprise.
Your experience with RedHat 6.2 on your single firewall box does not scale. It does need to be upgraded and tendered to. I would kill just for a stable kernel which could run NFS, would not panic in the VM or FS code under pressure, and wouldn't freak out under database workloads. The 2.4 kernel series is getting closer, but they keep on fixing one thing (e.g. NFS in 2.4.20 is pretty solid) and breaking something else (e.g. VM oopses are back in 2.4.20).
1) It's fun. Cute woman with mad martial arts skills kicks bad monster ass every week. How can you complain?
I've watched a few Buffy's and so far my impression is that Jennifer Garner would kick Buffy's ass all over the place. Maybe the bar for ass-kicking women has just been raised since the series started...
2) It's clever. It takes cliches and flips them upside down. Joss Wedon (the show's creator) has stated that the inspiration for the show was the typical cute blond who gets cornered and savaged by the monster in your basic horror movie. What if the cute blond was ready for the monster, and kicked its ass instead? Reversals like that are fun.
That isn't an impressive reversal these days. Its almost becoming as cliche as as the cliche it is based upon.
3) It's funny -- and the geekier your are, the more sly references you get and the more you appreciate the interesting things that the writers do with the English language. From one character's comment that somebody "makes Godot look punctual" to Xander's perfect sumnation of the effects of an all-night study session: "too much research...need beverage," the writers delight in bouncing their jokes off of culture high and low, and in simply messing around with the language.
Those jokes are kinda high school / college jokes. I dunno, maybe I've just moved on to the point where I only find jokes about Project Managers to be funny...
4) And, most importantly, the characters ring true. Every character on Buffy is well drawn, three dimensional. Even though they're combating fantastic monsters every week, the characters behave like real people, experiencing all the joy and hurt that real people experience. And the fantastical situations they run into are often just exagerations of events that all of us have experienced.
This is the defense of Buffy that I don't get. My impression of Buffy and Willow on the show is that both of them are just highly neurotic whiny high school girls. That isn't very interesting or appealing. And the fact that they're conflicted all the time doesn't give them "depth." Watching the show gives me the same kind of icky feeling that I get watching Ally McBeal.
Slashdot Mirror
Why does everyone keep speaking about EXT4 as if it's broken? It's working exactly as designed. It's the applications that need fixing, no?
Everyone expects filesystem to behave transactionally these days, so that if you follow the create-write-rename pattern that you either get the old contents or the new contents of the file. I just wrote this diatribe on the ubuntu bug report:
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781?comments=all
ted ts'o:
"You can opine all you want, but the problem is that POSIX does not specify anything ..."
I'll opine that POSIX needs to be updated.
The use of the create-new-file-write-rename design pattern is pervasive and expected that after a crash either the new contents or the old contents of the file will be found there, but zero length is unacceptable. This is the behavior that we saw with ext2 where the metadata and data writes could get re-ordered and result in zero-length files. With the 800 servers that I was maintaining then, it meant that the perl scripts for our account management software would zero-length out /etc/passwd, along with other corruption often enough that we were rebuilding servers every week or two. As the site grew and roles and responsibilites grew that meant that with 30,000 linux boxes, even with 1,000-day uptimes there were 30 server crashes per day ( even without crappy graphics drivers, a linux server busy doing apache and a bunch of mixed network/cpu/disk-io seems to have about this average uptime -- i'm not unhappy with this, but at large numbers of servers, then server crashes catch up with you ). And while I've never seen this result in data loss, it does result in churn in rebuilding and reimaging servers. It could also cause issues where a server is placed back into rotation looking like it is working (nothing so obvious as /etc/passwd corrupted), but is still failing on something critical after a reboot. You can jump through intellectual hoops about how servers shouldn't be put back into rotation without validation, but even at the small site that I'm at now with 2,000 servers and about 300 different kinds of servers, we don't have good validation, don't have the resources to build it, and rely on servers being able to be put back into rotation after they reboot without worrying about subtle corruption issues.
There is now an expectation that filesystems have transactional behavior. Deal with it. If it isn't explicitly part of POSIX then POSIX needs to be updated in order to reflect the actual realities of how people are using Unix-like systems these days -- POSIX was not handed down from God to Linus on the Mount. It can and should be amended. And this should not damage the performance benefits of doing delayed writes. Just because you have to be consistent doesn't mean that you have to start doing fsync()s for me all the time. If I don't explictly call fsync()/fdatasync() you can hold the writes in memory for 30 minutes and abusively punish me for not doing that explicitly myself. But just delay *both* the data and metadata writes so that I either get the full "transaction" or I don't. And stop whining about how people don't know how to use your precious filesystem.
It's actually quite a geeky activity. Although being unfit makes decompression sickness more likely, it's not an activity that requires much in the way of physical prowess. There's maths in those dive tables, or if you prefer gadgets there's dive computers. Not that there's not plenty of gadgetry involved in the breathing apparatus side of things.
It goes a lot beyond that as well, when you get into technical and cave diving.
I'm continually drawing parallels between my experiences at Amazon managing 30,000 servers, and cave diving in terms of the philosophies that are successful. You can't be successful managing that many servers if they are all unique, there has to be standards and there has to be uniform reactions among the operational staff for any emergencies to reduce MTTR. Underwater it takes on an additional urgency since your reactions to emergencies involve lack of breathing gas and your "MTTR" needs to be in seconds. There's also principles of failure analysis and single points of failure which cross over fairly easily. There's also more nebulous principles such as resisting the urge to solve problems in advance of actually encountering them -- which draws me towards Agile simply for the You Aint Gonna Need It - YAGNI principle - for reducing the complexity of designs. And the law of unintended consequences applies in both disciplines -- trying to fix a problem you don't actually have can cause problems elsewhere.
That's not even getting into the way that some people get geeky about being underwater. There's a whole different set of wildlife down there to get geeky about, and most divers love to find some new animal underwater and figure out what it was they saw online by consulting other geeks who can ID the critter. When cave diving there's a whole different set of geekery involved in the environment of the cave that I don't even know a tiny fraction of so far. And with wrecks, there's the whole history of the wrecks, as well as the geekery involved in going out and doing the historical research and side scanning and finding new wrecks.
Diving really has a nearly unlimited ceiling on how geeky you can get about it.
Spend any time at 40m, and just make sure you know what you're doing; deco stops come into play very quickly.
40m/130ft is actually a baby technical dive. Its easy to do an hour-long dive on wrecks at that depth and do only very minimal O2 deco with minimal risk.
I got interested in technical diving after having done a day where we did 2 recreational 30-minute dives to 30m and got narc'd, while the technical divers on the boat both did 2 60-minute dives using helium to reduce narcosis and penetrated the entire length of both wrecks that we dove on. I've since gone back there and done both of those dives again as technical dives, and added scooters so that we spent a bunch of time zooming around a viewing the entire outside of the wrecks. Very fun dives.
60m/200ft is a whole different ballgame, and 90m/300ft is yet another ballgame, entirely.
There was a Japanese sub that sank off the coast of Hawaii that people dove. It was in about 140 feet of water, but the top deck was at 110 feet. Remember, unless your suicidal or stupid (or working for the Discovery Channel), you don't actually go under or into the wreck; you just go near it and around it. For PADI, wreck dives are one of their advanced courses.
Or unless you're simply certified to penetrate the wreck, and ideally this includes both courses taken on wreck penetration (and cave diving), along with more long-term mentoring with other experienced wreck divers.
It may be a little crazy, but I think that people who jump out of perfectly working airplanes for fun, or like to climb up sheer rock faces are absolutely nuts. Wreck diving (and cave diving) are far from suicidal if you just get the training, experience, mentoring and follow some basic rules.
Artificial reefs are also very useful for wreck diving n00bs. As a n00b, myself, so far I've only got 24 cave dives under my belt, and two wreck penetration dives on the Saskatchewan and Cape Breton up in Nanaimo, British Columbia (artificial wrecks). The newly sunk artificial reefs are somewhat safer for newbie wreck divers since they have been 'cleaned up' and have less crap that you're going to get caught on, so that less experienced wreck divers can get experience executing dives in an overhead environment with less crap inside the space, no wires hanging down waiting to grab ahold of scuba gear, etc. Although given the fatality on the Cape Breton and the triple-fatality on an artificial wreck in Florida fairly recently it is not without risks (both of those incidents involved violation of training standards).
I also don't believe the PADI wreck diver certification trains a diver to enter wrecks. It is about diving on wrecks rather than in them. You have to go to do a different (technical) dive training agency in order to get trained to dive inside wrecks.
I'm not basing this on computer models, I'm basing it on observation. For a million years and multiple ice age cycles there has been correlation between changes in solar insolation due to changes in the orbital parameters of the Earth (modulo a couple supervolanoes, etc). This correlation also establishes an upper bound on the intrinsic variability of the Sun's output over the past million years since if you increase the intrinsic variability of the Sun enough you would destroy the correlation between the Earth's orbital parameters and the Ice Ages. That is experimental evidence, not computer models, and has nothing whatsoever to do with CDO valuation models.
So we can state that the effect you suggest of having the Sun dim enough to cause an Ice Age, has not been a factor in climate change for the past million years.
We also have experimental evidence which shows a decline in temperature of about 0.2C due to the Maunder Minimum when sunspot activity went away. That sets a reasonable bound on what to expect from solar variability.
So, unless you have some evidence of a fundamental change in the way the Sun has worked for the past million years, I'm heavily betting that the worst that could happen is a new Maunder Minimum with a decrease of about 0.2C, and what is vastly more likely is that the new sunspot cycle is going to start soon and all this will blow over.
And just because Outliers can happen doesn't mean that you get to make up whatever you want. The collapse of CDOs and their valuation models was foreseable (I've been in cash since 2004 and warren buffet saw this trainwreck coming), because it was obvious that their statistical basis was fundamentally flawed and that they had no way to price in a bad recession. There's no similar obvious flaw in solar models or our historical understanding of solar output.
And the fundamental mistake that was made in the financial sphere by everyone (once again) was assuming that "this time it is different". That mentality is behind every single financial bubble going back for as long as there are records. And arguing that we're suddenly going to enter an Ice Age due to some kind of solar minimum is "this time it is different" mentality. Not only are you assuming that this solar cycle will deviate from the pattern over the past several hundred years, but will exceed the pattern over a few thousand years and create a once-in-a-million years event, pluging the world into an Ice Age. Typically it doesn't work that, patterns and cycles tend to repeat. My money is on a mostly normal new solar cycle.
No it wouldn't lead to an ice age.
Another Maunder Minimum elimination of sunspot activity might cool the climate by about -0.2C which would unwind 2 decades of global warming and get us back to the 80s or so. Solar cycles, however, are not important in generating ice ages, the ice ages are triggered by the Milkankovich cycles -- which is ultimately solar in nature but the variability is due to changes in the Earth's orbital parameters and not changes in solar output.
El Nino cycles in the pacific ocean are more important than the solar cycle:
http://www.realclimate.org/index.php/archives/2008/07/global-trends-and-enso/
Also, if you measure ocean temperature, not air temperature (oceans have a higher heat capacity than air), there has ben no lull in global warming:
http://www.realclimate.org/index.php/archives/2008/06/ocean-heat-content-revisions/
"But half the companies out there aren't actually doing anything complicated."
Well, I'm responding to a very strong statement saying that cloud computing will "make centralized IT go away". And while it may do so for small business, which needs a couple dozen servers to run some "web 2.0" apps or a storefront or whatever, I doubt it will have much of an impact on the IT staffs at S&P 500 companies.
If you look closely at Amazon's SLAs as well, they aren't going to be acceptable to most large companies. Financial institutions might be able to outsource some offline batch analysis and model crunching to EC2, but their online transactional processing that needs just stupid reliability isn't going to be transferable to Amazon's cloud.
You are correct though that by sheer number, most companies are small and most companies don't have very complicated IT needs. However, "cloud computing will make centralied IT go away" is just silly if you've got a background at centralized IT at large companies.
There will still be a lot of IT out there, it may just be bigger IT, and some of the small IT may be eliminated, or it may turn contract work.
Cloud computing doesn't make centralized IT go away.
Amazon EC2 only provides you with servers. You still need system admins to configure and run and debug the boxes if you're doing anything remotely complicated.
It does solve provisioning issues, procurement issues and lights-out management. But that is just a sliver of centralized IT.
And having Amazon provide "remote hands" for you to replace failed hardware is not even a "centralized" part of IT. Even without cloud computing you shouldn't have your IT organization tightly coupled to where your sites are. All that you need is the occasional physical hardware replacement, and management of the facilities (power, cooling, etc).
Actually, the obvious way to prevent against DNS attacks on the authentication server is to have the user's client have already setup trust to the authentication server when the identity was initially setup. Then the client would cryptographically check to see that the authentication server the website was trying to use was the trusted one. There would still be attacks possible via impersonating the website itself, but those risks currently exist as well. This approach also could be useful to fix phishing attacks. If you only allow this kind of authentication to a given website and the client webserver does no kind of fallback to password auth, then the phishing site cannot gather any passwords, and if they try to proxy to the authentication server all they get is a challenge/response authentication which is useless to gain access to the site they are trying to exploit. So you could successfully login to a phishing site without giving them anything in that process. They'd need to then trick you into giving further access to credit card data, etc.
The nice thing about this approach is that I can run my own authentication server on my own domain in the machine's in my home just like I currently run my own website and sendmail instance. Then the passwords are entirely stored and managed on machines under my own control and I can setup policy about which websites I trust and how much I trust them.
For less astute internet users, their ISPs could setup authentication servers, just like their ISPs setup sendmail and DNS for them.
Although, looking through the OpenID spec it seems fairly blog-centric and it reads like someone's first attempt at writing an RFC...
Nope.
The security win here clearly goes to OpenID. With OpenID you only have one password to manage and remember which means you can use good password management practices and rotate/change your passwords on a frequent basis. If it does challenge/response authentication correctly you should also be able to make sure that attackers that 0wn the website you are visiting cannot use your credentials to attack your accounts on other sites. I haven't looked that the OpenID spec for more that 5 seconds, so I don't know how it works, but the correct way to do this is for the intermediate site to proxy a challenge/response authentication session to the OpenID authentication server and then to get a response back indicating if it succeeded or not. The big security hole here will be that the intermediate website you are trying to authenticate against will need to securely be able to contact the authentication server. The obvious attack is against the DNS entry of the authentication server to point it to a fake one which always returns that authentication succeeds. I'm not sure if OpenID has thought of a way around this or not yet.
I had a similar idea several years ago, but I would have implemented it by extending DNS using another record like an MX record so that people could use their e-mail addresses as IDs which would lookup an authentication server based on the DNS zone record, and would then contact that server to do challenge/response authentication. This sounds like the same kind of thing only adding the web and URIs on top of it.
...I mean the skills summary is a bit silly, but that is probably an artifact of the database that the listing is in, and that the submitter wanted a wide audience of potential applicants.
What they're looking for is a bilingual windows drone sysadmin to take care of their machines. Speaking from experience looking through resumes, there are a way too many mediocre or sub-mediocre system admins out there looking for a job (and I look thorugh unix resumes -- I've heard the windows ones are worse). Paying them $40k -- even CDN -- is probably being generous.
Most system admins are bad at what they do. I don't know why anyone would think they should all get paid $80k a year...
If you aren't a bad system admin, then you should realize that the $40k job listings are communicating to you that those aren't the jobs for you. If you had the job, in addition to being underpaid, you'd probably be unchallenged and bored.
of course if you've got a cluster of 100 machines that are all doing the same things and you can even make the app go 5% faster by a different filesystem, that can be a saving of $20,000 or so.
http://venus.nildram.co.uk/veganmc/insulin.htm
I don't think this did anything to debunk the "insulin thinking". In fact this data might explain why I had more success losing weight when I was eating apples than when I've been eating grapes. I hope the authors publish more data on more foods for this index.
This was one of the reasons why I did not like the information in "The Hackers Diet". The author completely ignored the fact that the major benefit of excersize is *not* how many calories you burn during the excersize, but how much it increases your metabolism. Excersize is more important to weight loss than he makes out.
He also ignored the effect that highly glycemic foods that spike insulin levels have on your hunger levels and your food consumption. He argued that you should reduce calorie consumption, but gave no suggestions other than calorie counting on how to achieve this.
Regarding the carbs fiasco - I guarantee you, if I eat 1 pound of carbs, and you eat 1 pound of fat, you will put on twice the weight as you consume (more than) twice the calories.
I've been following a low-glycemic diet similar to what you suggest (balanced diet low in simple carbs, low fat and low cal). I've found that when I cheat by eating red meats (and I can still pack away an awful lot of calories -- particularly with kosher dogs) then I don't gain weight -- although I don't lose weight either. The problems that I have are when I start to eat white breads (the hot dog buns) and then I start to gain weight.
My experience tends to suggest that its not merely calorie intake, similar to what the Atkins people claim.
Sorry to disagree, but I've been doing a low-glycemic diet for the past 6 months and haven't found this to be true. For the diet that I'm on I try to stick to a low-fat, low-glycemic, low-calorie diet in order to lose weight. I've found that I can occasionally gorge on high-fat high calorie foods like hot dogs and steak and while I stop losing weight I don't tend to gain weight. The problem that I have which causes me to gain a few more pounds is when I start cheating on the white bread. Then I usually put a few pounds back on and find myself feeling "addicted to carbs" and have to go through withdrawal again and get back on track to losing weight.
I believe the biochemical mechanism behind this might be that the problem is insulin levels. For example, there have been studies that rats don't gain weight when whey they have the insulin receptors on their fat cells mutated so that insulin won't bind to them. Similarly I find that I gain weight when my insulin levels are high and not simply when my calorie intake is high.
Anyway, I've found Atkins to be overly-simplistic and I've successfully lost weight through a diet which according to the Atkins people you can't lose weight on. At the same time I'm not putting my health at risk through eating too much bad fat or through the effects of ketogenic diets (and my breath doesn't smell).
Also, you get the same benefits: higher HDL, lower LDL, reduction/elimination of type II diabetes risk and reduced blood sugar volatility. And I've got a more varied diet (my diet is a super-set of the Atkins diet) and is more sustainable over the long term.
It also makes a lot more sense anthropologically. Humans have been able to not gain weight off of both high fat animal product diets *and* low fat high carb diets, but it has been since we've gotten such a highly glycemic diet that the obesity epidemic in industrialized countries has exploded (and its worst in the US where high fructose corn syrup is added to *everything*).
No, actually, you don't get it.
In order to survive in the IT industry in the US you're going to have to be able to be both literate in Unix and be able to do all the technical heavy lifting, and you're going to have to be able to do all that "meaningless wank." All of that "meaningless wank" isn't meaningless when you've got a department of technically capable people who are drowning under the workload of tickets, pages and box build-outs and have no idea how to make their life better. In that circumstance you need to be able to understand how to fix an IT department to make it run better in addition to be able to fix computers to make them run better. If you can't do that, you won't be the one surviving, you'll be the one that your management will get fed up with and fire or outsource you eventually to someone who has found a clue. The gravy train that you've got from being the insufferable unix guru with attitude is going to dry up. Your making it a virtue to ignore anything related to running a business as being "meaningless wank" is what is going to get you canned, and I'm going to laugh...
Yes. But in the future it won't be enough to merely understand how computers work in order to make it in the IT field. You will need to understand how an IT department fits within the overall structure of an organization and how to meet the requirements of your internal customers. You will also need to understand how to scale your IT services within the organization. There are entirely too many bad system administrators out there who really need to get either educated or purged, and even the current IT downswing hasn't been able to do it. There are still too many people who are in the IT job market who should simply stop sending their resumes around. 1999 is over, and you weren't that good.
If you can't think beyond "this machine is broken, here's how to fix it" to "this process is broken, here's how to fix it" then don't bother going into IT. There are already way too many people who are perfectly technically capable in IT but who have no idea of how to solve, or in some cases even identify, a larger problem.
(And yes, I had a bad week at work)
Of course if the economy, the stock market, and their stock value starts to increase again, then they can still keep the pyramid scam going.
Don't believe me? Here's how it works: Microsoft prints up some new employee stock options. Those employees eventually buy their stock options and give the money to microsoft. Microsoft pockets that money and reports it as *earnings* instead of an expense. That money then goes into their statement as profits and cash.
This is no different from a company which continuously offers new stock for sale every year. But in that case you would never consider that sale of stock to be profit. It is a way of raising money, just like a company going IPO to raise money. But it doesn't reflect on the health of the company and eventually the company can burn through it all. In fact, these kinds of liquidity events should drive the stock price down since you're issuing more stock and diluting the other holdings.
In the case of Microsoft, though, these rules do not apply. In fact since microsoft reports all this cash as earnings then it looks like Microsoft is unreasonably profitable. They then can support really, really silly market capitalizations which pushes their stock price up -- this causes people to invest in them, and causes them to be a major holding of index mutual funds. Then the whole cycle continues...
Contrast this to linux where you have to mantain 3-5 different kernel versions at a minimum. And certifying a kernel version is a lengthly process, with no assurances that the issues you've had in previous kernels have been addressed or that there will be no new issues which are added (in fact, it seems like you can count on later kernels breaking something which was previously stable).
To use this silly metaphor, some puppies are fairly low maintenance and some get diarrhea on the carpet..
The problem is that the people who are writing the open source code do not understand how to keep TCO costs down. The open source community is by-and-large a community of software developers who don't want to be burdened by the issues they had working for corporations. A prime example of this is the open source "release early, release often" mantra which is practically hostile to any use of open source products in the Enterprise market (which is the only market that really cares about TCO). If you release early and often you continue to introduce bugs and you never stabilize a release (and I spend a lot of time in my job dealing with 2.4.x kernels in an enterprise environment, and it is *not* a stable kernel branch -- no matter what people might think based on their limited experience with a handful of Linux boxes that they admin). By releasing early and often you also produce conniption fits with third party vendors, who need a lead time to QA test their products on the stable release and who expect the release they're targetting to be supported.
If open source software is going to compete with commercial unix products, the open source development community is going to need to grow up. They're going to need to start releasing code which becomes progressively more stable, which is more thorughly QA'd and regression tested, and which has a better development model.
I don't know if this can happen. It really requires the presence of people who have a substantial amount of control and who are getting paid to do jobs like program management that people normally don't do for free. It might happen if RedHat or IBM or another big player (or consortium of players) officially forks the Linux kernel. I don't see any way of it happening given the current development model (within the Linux kernel at any rate).
FreeBSD gives me a little bit of hope. At least the FreeBSD community seems to understand that they're not writing the code *just* for themselves and that they have a userbase that would like their code to run on servers in a stable fashion. The Linux community seems to largely be self-masturbatory developers who just want it to run faster, and don't care if their end users are getting paged at 2AM in the morning due to panics in the supposedly-stable kernel series.
Try running 1000+ Linux boxes with hundreds of different workloads and configurations (something more difficult than just stamping out a 100 identical machines in a beowulf cluster). Come back to me and tell me that Linux is better than commercial unixes for management in the enterprise.
Your experience with RedHat 6.2 on your single firewall box does not scale. It does need to be upgraded and tendered to. I would kill just for a stable kernel which could run NFS, would not panic in the VM or FS code under pressure, and wouldn't freak out under database workloads. The 2.4 kernel series is getting closer, but they keep on fixing one thing (e.g. NFS in 2.4.20 is pretty solid) and breaking something else (e.g. VM oopses are back in 2.4.20).
I've watched a few Buffy's and so far my impression is that Jennifer Garner would kick Buffy's ass all over the place. Maybe the bar for ass-kicking women has just been raised since the series started...
2) It's clever. It takes cliches and flips them upside down. Joss Wedon (the show's creator) has stated that the inspiration for the show was the typical cute blond who gets cornered and savaged by the monster in your basic horror movie. What if the cute blond was ready for the monster, and kicked its ass instead? Reversals like that are fun.
That isn't an impressive reversal these days. Its almost becoming as cliche as as the cliche it is based upon.
3) It's funny -- and the geekier your are, the more sly references you get and the more you appreciate the interesting things that the writers do with the English language. From one character's comment that somebody "makes Godot look punctual" to Xander's perfect sumnation of the effects of an all-night study session: "too much research...need beverage," the writers delight in bouncing their jokes off of culture high and low, and in simply messing around with the language.
Those jokes are kinda high school / college jokes. I dunno, maybe I've just moved on to the point where I only find jokes about Project Managers to be funny...
4) And, most importantly, the characters ring true. Every character on Buffy is well drawn, three dimensional. Even though they're combating fantastic monsters every week, the characters behave like real people, experiencing all the joy and hurt that real people experience. And the fantastical situations they run into are often just exagerations of events that all of us have experienced.
This is the defense of Buffy that I don't get. My impression of Buffy and Willow on the show is that both of them are just highly neurotic whiny high school girls. That isn't very interesting or appealing. And the fact that they're conflicted all the time doesn't give them "depth." Watching the show gives me the same kind of icky feeling that I get watching Ally McBeal.