So imagine a system that works like GPS but the "stars" in this GPS system are in a solar "stationary" orbit. Your super precise time piece can compute your time by observing your location on the globe and where that location on the globe is relative to the sun. In other words you would SPS (Solar Positioning System) your location in the solar system and from that compute the time.
Don't rely on lookup tables to tell you where the Earth is... look at where the Earth actually is.
Ahh. I did not see the difference between the two systems because I gave you far too much credit and stopped reading after the first paragraph or so. Now I understand. TAI is (despite a few caveats) an implementable solution to a real problem, while your idea is not.
Let's imagine that we've designed this "solar positioning system" and it works. Combined with the existing global positioning system, we now have a way (on machines with correct instrumentation, favorable atmospheric conditions, etc) to determine current position in the solar system (with some uncertainty). By the existing global positioning system, I know my current position on the earth (with some uncertainty). On a good day, when everything is working, of course. I'll be generous and assume for the sake of argument that today is the day it works, and that the precision is infinite. Given this, I can calculate the earth's current position relative to the sun.
This really doesn't solve the problem of how to convert an arbitrary number of seconds since some epoch (in a particular reference frame) into its equivalent calendar time on Earth, much less an arbitrary planet. For that, it is not enough to know earth's position relative to the sun. It is also necessary to know where the earth has been relative to the sun, for we define dates in terms of rotations completed, not absolute position. In the case of future dates, we also need to know where the earth will be relative to the sun. This last bit is an unsolved problem. All the king's horses and all the king's men have tried it, and the best they can do is tell us where to stick leap seconds with six months' notice. Now, while every machine could attempt to duplicate this effort, I fail to see the point. Distributing the leap second table - rather distributing the entire computational model and attempting to regather the current data on each machine - is simpler, does not require distributing esoteric hardware everywhere or launching solar satellites, can be used everywhere (even where reception is bad), is computationally feasible, uses less bandwidth, is vastly more reliable, and achieves consistent results between machines.
It has always seemed to me that there should be computer epoch time and then you should have a conversion from that epoch into a time that make sense for the user. So, computer time units could be fixed to the vibrations of your favorite atom and human time could be fixed to the orbit and spin of your favorite planet. And all systems would do a conversion between the time systems at display. Different systems could do different conversions. Applications programmers could remain oblivious to the conversions if all time was stored in a universal fixed format independent of any particular planet, orbit, or galaxy.
The computer time system you've just described is known as TAI. There are some catches, though. In particular, leap seconds are only guaranteed to be posted six months out, so you can only convert TAI<->UTC for times up to six months after your last download. That has a bunch of consequences:
To be fully rigorous, time-handling libraries would have to handle downloaded leap seconds tables (I think NTP does this but I don't think there's a standard for it within the system) and give a choice of error or degraded accuracy if a conversion is too far in the future.
If you want a canonical format that's guaranteed to be precise and accurate (even if the machine hasn't been on the network since installing from media), it's gotta be TAI...so it will be (currently) 33 seconds off from the wall clock.
just more care in general about time data types.
conversion hassles.
In most cases, it's probably not a big deal if something a year out is a couple seconds off, but every now and then someone really cares.
If the government forced you to rent your car out for 50% less than it cost you to rent it, would you be happy about the deal? Probably not.
I don't understand your comparison. Vonage customers pay a conventional ISP (say, Verizon) for broadband service (e.g. DSL). Are you saying that the government is forcing phone companies to sell DSL at below cost? Please share details, because I'm not getting that deal. Is it only available to Vonage customers? I'll sign up right now.
(Moderators, if cdrguru does not post a verifiable answer to my question, please mark the parent as a troll.)
Then we can start to make changes to the houses so that the epidemic of lung diseases can be tackled. This is due to the houses not having chimneys and all cooking is done over an open charcoal fire.
Be careful there. I don't know the situation in Madagascar, but let me relay a story I heard which is possibly relevant:
In East Africa, Peace Corps volunteers wanted to improve the design of the huts the Masai would build. They taught them to incorporate a large vent, eliminating the smoke build-up. Worked beautifully, at least until malaria went totally out of control. Apparently the smoke kept the mosquitos out, so the pre-Peace Corps design was a reasonable compromise - lung diseases are preferable to malaria.
If you ask Oracle - they didn't fork it. They are just offering support and patches to RHEL - and pulling out all the proprietary RH stuff so that they can put it out there themselves, at least that is how I understand it.
"All the proprietary RH stuff" is just some trademarked logos and occurrences of the literal string "RedHat". That's about the only difference between RHEL and CentOS.
The Linux-Watch article you linked to doesn't make sense, either:
The database giant claims that Red Hat only provides bug fixes for the latest version of its software. Thus, Oracle executives say, this often requires customers to upgrade to a new version of Linux software to get a bug fixed. Oracle's new Unbreakable Linux program, on the other hand, will provide bug fixes to future, current, and back releases of Linux. In other words, Oracle will provide the same level of enterprise support for Linux as is available for other operating systems.
If they'd done even the slightest bit of research, they could have compared that to RedHat's claims of seven years of maintenance. If they wanted to do actual journalism, they would have pressed Oracle for specific examples of times RedHat has fallen through on that promise and (if they'd given any) seen what RedHat has to say in their defense. As far as I've seen, RedHat's support is as good as advertised.
here's a TLS extension, Server Name Identification (http://www.ietf.org/rfc/rfc4366.txt), and an HTTP Upgrade: header approach (http://www.ietf.org/rfc/rfc2817.txt).
I'd say there's a clear winner there. I don't think anyone thought RFC 2817 through. It suggests (though does not require) sending the initial request in plaintext (ugh), and there's no good mechanism to advertise the server support without penalty on first hit to a https URL (i.e., advertise in the URL or DNS records). Since no existing servers support it, this means for browsers to take advantage of it, they'd have to connect to existing servers on the http port, discover the lack of support, then fall back to normal https. So all sessions to existing https sites would be slowed down by at least two round trips (c->s SYN, s->c SYN/ACK, c->s request, s->c failure), or say 150 ms. I'll pass.
RFC 4366 is much better. No speed penalty - there's no need to advertise server support - the client can always send the option. The server ignores it if it doesn't understand, so without server support the status quo is maintained - the server admins shouldn't put more than one vhost on the same IP until they upgrade. When the client and server both support it, everything works fine. When the client doesn't support it, there's a security warning - about as good a failure mode as you're going to get with a protocol upgrade like this. And the client support is already there in the latest versions of Internet Explorer, Firefox, Safari, and Opera.
I think consensus is moving towards SNI, and a reasonable chunk of the browsers seem to support it (though OpenSSL does not yet until 0.9.9 comes around). The Apache project is also dragging its feet, waiting for a clear consensus towards one or the other, AFAICT.
I think the Apache people are waiting on OpenSSL 0.9.9. bug 34607 (copy'n'paste the URL; don't follow the referral from slashdot) has a patch with support, but it is not effective without OpenSSL 0.9.9. I'm looking forward to it myself...tempted to install a development build just to have this feature, but probably not a good idea to use untested security software.
She might have been an unusually efficient walker, but there are limits, and she did other things in the day
I just found this emperical study which found that "obese individuals are less efficient than lean individuals during normal-speed walking". It looks quite thorough. So in fact, I'll take that back: she was likely not an efficient walker. Again, if she really walked that much, she ate that much, too.
Ok, you are a typical idiot, but I will even elaborate with a story. I had a girlfriend in high school. We dated for a little over three years. Being young and nieve, I always wanted to be with her. Before I go further, she was heavy... ~5' 6", 200lbs. I was 5' 7", 130lbs. After school, she would WALK from her house to pick me up, we would WALK back to her house, she would WALK me home, then WALK home herself. Now this is the part where you have to pay attention. I am not exaggerating in the slightest... in my parents car, one way to her house was 6.2 miles. We walked on the very sidewalks along said roads. That is almost 25 miles of walking... in ONE DAY. And we did this practically EVERY DAY (I liked the sex, she was needy). And here is the best part... she never ate lunch at school. She usually had dinner at my house.
Exercise and diet always cut it, unless your girlfriend was a perpetual motion machine. According to this chart, walking at 3.0 mph for a 190-pound person burns 300 calories per hour. Four 6.2 mile trips at 3.0 mph is 8.3 hours of walking, or 2,500 calories. She might have been an unusually efficient walker, but there are limits, and she did other things in the day. If what you said was true (and I doubt it...eight hours of walking? really?), she ate more than 2,000 calories a day. You may not have seen her do it, but she somehow managed to cram in a lot of eating in the time between school, sex, eight hours of walking, homework, and sleeping.
An AC said further:
It's quite plausible that there are people whose body needs 20 hours a day of constant sprinting and one stick of celery a week to maintain a healthy weight.
No. In fact, it's not merely implausible, but actually impossible. Your belief system is thermodynamically unsound.
Still an unbelievably bad idea to use getpid() as a source of randomness. Portability and readability aside, it reminds me of this xkcd comic:
int getRandomNumber() { return 4;// chosen by fair dice roll. // guaranteed to be random }
However random the method for generating the pid was, it's only chosen once over the lifetime of the process. So how many times does qmail use the same random number?
If a developer just can't understand the code (because it needs cleanup or it's just very complicated), then it should be cleaned up and commented properly.
To rephrase only slightly, if it just needs cleanup, then it should be cleaned up? Well, yes, but you haven't said anything that's not obvious.
I'd say the real question is always "is the design right?". When I've worked with big chunks of existing code, I've rewritten it in only when there's an aspect of the design that's totally wrong and has infested nearly every line. Off-hand, I can only think of two classes of such mistakes:
wrong threading model. For example, I inherited code for a multiplexing protocol that had this ridiculous hierarchy of one thread per connection, one thread per channel, and then dispatching to a pool of workers. It was difficult to understand, slow, and would mysteriously fail based on load. (Completely full of race conditions.) I rewrote it as one thread that did all the IO asynchronously and the pool of workers. Much less code, problems all went away.
wrong programming language. Several times I've replaced a mountain of C or Java with a molehill of Python.
Otherwise I've refactored - eliminated duplicate code, reorganized to fix broken abstractions, removed unnecessary overengineered design patterns, fixed function names, added comments, switched libraries, corrected error handling, fixed bugs in general, etc.
Keep in mind that AT&T is turning on more cell phone accounts at once than anyone has ever done in the history of the cell phone industry. iPhone sales have either hit a million units already, or they will by the end of the coming week. If they perform at 99.9%, that's still going to be a thousand people running into problems.
How is that possible? They are only selling in the US, correct? The population of the US is 300 million. Of that, I'm going to say only the 20- to 64-year-old group is at all likely to buy an iPhone. That's 180 million people, according to Wikipedia. Are one out of 180 working-aged Americans really standing in line to buy an iPhone in the first week?
Well, I've been to Nairobi, and it's quite similar - all homes in Karen and Langata (the rich suburbs of Nairobi) are small fortresses, with alarms, barbed wire, fences and dogs. You see askaris (armed policemen) everywhere in downtown Nairobi, and, when arriving at a hotel, they inspect the underside of your car for bombs. And from what I read, Nairobi and Jo'burg take turns being the crime capital of Africa. Especially lately, because of the war in neighboring Somalia, armed robbery and other attacks have grown a lot.
I've been there as well, and that's not quite my impression. I stayed a couple nights at a house in Karen. There were fences and dogs, yes. (Big dogs, but not the kind that would tear an intruder to shreds. More the kind you'd have on a farm anywhere in the world.) No alarms or barbed wire, though there might have been if a nearby military base didn't make it largely unnecessary. However, my hosts told me that was more to prevent theft than violent crime.
We went through poorer (supposedly insanely dangerous) areas as well - my host took us along in a Land Cruiser as he looked for car parts in the Industrial City, and my friends and I biked through Dagoretti Market on our way out of town. Again, our hosts warned us about theft but told us we'd be safe enough. And we made it. There was one guy who yelled obscenities as we went by, but almost everyone was friendly and curious about the three wuzungu with fancy bicycles. (Actually, that held for my entire trip through Kenya and Tanzania, which was rather off the beaten path.) In fact, we saw a lot of genuine hospitality and kindness.
As for the armed policemen...yeah, I saw those, too, and I heard stories of widespread small-scale corruption. My host described a typical one: a policemen told another guy he needed to pay some ridiculous made-up-fine. The other guy let the policemen talk himself out, handed him half the claimed fine in cash, said "fuck off and go have lunch", and drove away.
[Considering] the fact that the "nv" driver is buggy there is a lot of room left to improve on here.
Definitely. Having a high-quality open source drivers is not just about having 3D support. As is, there's simply a choice between a mostly-good proprietary driver and a horrible, incomplete open source driver.
"nv" driver does not support all cards, has bad artifacts on my GeForce 6150, and fails to use DVI on large video modes with "NV(0): Mode "1920x1200" is larger than BIOS programmed panel size of 1280 x 1024. Removing.". (See bug 3654.) The nvidia people on the bug (look at the email addresses) said that they couldn't fix it with any but the latest GPU. That's obviously false...the proprietary drivers work fine.
nVidia won't fix the open source driver or give anyone else the information to do so, so a reverse-engineering effort is necessary.
Essentially have barrier calls in most places you'd have sync calls -- and yes, maybe fbarrier or fdatabarrier, like fsync/fdatasync. Note that sync-ing already does basically the same thing, just slower.
Yes, and since fsync() is a working but suboptimal fbarrier(), you can writable portable code easily:
There are a couple of problems with that approach, I think. The most obvious one is that essentially, your application is trying to implement a transaction, and your filesystem will, if it's smart, group these into a transaction. In other words, if I read from file a, write a new version to file tmp, barrier, and then rename that tmp to a, then barrier again, all before the FS writes it out to disk, a smart enough FS might figure out that I want to atomically update a, and skip the tempfile altogether. Skipping the tmpfile means skipping dealing with allocating a new inode, setting a dozen timestamps, then unlinking it, when it might be faster to simply use the FS's own journal. (Or it might use the tmpfile anyway, if it thinks that's faster.)
Yeah, directly making an atomic change to the file would probably be faster. And there are many places that full ACID would be convenient. But there's also a lot of stuff running that doesn't need transactional semantics, and I'd expect they'd be a lot slower for it. Also databases that have their own transactional systems with different performance characteristics. This seems like a global change, and I'm not sure that's desirable.
Anyway, the transactional semantics you're describing exist, in Microsoft Windows of all places. I don't know much about them, what with hating both Microsoft and Windows.
It's my understanding that this is also approaching problems at the hardware level. For instance, tagged command queuing and friends, disk write buffers, and the general nature of the media (and the fact that you don't actually know what the physical media is) all means that your only guarantee is that when your fdatasync returns, the data is safely on disk. Maybe. Hopefully.
Well, what hardware guarantees may or may not be available is the filesystem implementator's problem. I want to know what the filesystem implementation can guarantee to me.
I'd suggest reading this, this, and this. I suspect similar techniques can be used on a large file inside of an existing filesystem -- which would also blatantly make my point about duplicated effort. But beyond that, I'm really not sure.
I've read those, but they don't really help. They're focused on metadata, and I want to know what guarantees I have for data.
No really, you want to install tubes in your walls (often called smurf tubes) and put your cat5 or whatever inside the tubes. If in the future you want fiber, or whatever the future finds you just push new cables down these tubes.
If it really is that quick and easy, then I agree. Definitely put them everywhere, though - no one would say one power outlet per room is enough, so I'm not sure why you'd say such a thing for a network drop either.
Put two things of Cat 6e and a thing of Coax to each room, 6e is not that expensive drag the wires to the wiring room put them on their own rack
Wikipedia doesn't mention such a cable. Do you mean category 5e? category 6? category 6a? The last is what I'd suggest, as apparently it will be needed for 10 Gigabit Ethernet. Seems to be pricey, but probably less than snaking new cables through everywhere or tearing apart walls.
Fiber is pointless because its for long haul really (at least in its current version), you need fast switching, which as far as I am aware doesn't exist for fiber.
I say put in generous amounts of category 6a anywhere you might want a computer or television (more than one per room, especially to prevent things like patch cables running around doorways) and coax where you might want TVs, but consider also adding fiber. Gigabit Ethernet won't be considered fast forever; soon you'll want 10 GbE, then 100 GbE, and so on. What is the limit of category 5e? category 6? category 6a? What is the limit of multi-mode fiber for your distances? single-mode fiber? How much extra would it cost to put in more/better cable before the walls are finished? How much extra would it cost to put in more/better cable afterward?
I think the POSIX filesystem API is too simplistic and low-level to do this properly. On ordered filesystems, tempfile-then-rename does the Right Thing -- either everything gets written to disk properly, or not enough to hurt anything. Renames are generally atomic on journalled filesystems, so either you have the new file there after a crash, or you simply delete the tempfile. And there's no need to sync, especially if you're doing hundreds or thousands of these at once, as part of some larger operation. Often, it's not like this is crucial data that you need to be flushed out to disk RIGHT NOW, you just need to make sure that when it does get flushed, it's in the right order. You can do a sync call after the last of them is done.
Problem is, there are tons of other write operations for which it makes a lot of sense to reorder things. In fact, some disks do that on a hardware level, intentionally -- nvidia calls it "native command queuing". Using "ordered mode" is just another hack, and its drawback is slowing down absolutely every operation just so the critical ones will work. But so many are critical, when you think about it -- doesn't vim use the same trick?
What's needed is a transaction API -- yet another good idea that was planned for someday, maybe, in Reiser4. After all, single filesystem-metadata-level operations are generally guaranteed atomic, so I would guess most filesystems are able to handle complex transactions -- we just need a way for the program to specify it.
I was with you in the first paragraph. I expected you to lead up to "high-performance applications need a barrier - ensure operations this process performed before the barrier hit disk before operations it performs after the barrier()". Or for even higher performance, a more precise barrier that takes inodes or file descriptors: "the operations performed before on inode A hit disk before the operations performed after the barrier on inode B if a call to". I don't quite understand you leap to a transaction API. It seems useful (it would be cool to have full ACID on filesystem operations, even ones that span multiple files) but I'm not sure it's the way to get the best performance.
By the way, you seem knowledgeable on filesystem semantics. I've been wondering something for a while, and I haven't had luck googling the answer. If I call write() on a section of a file and then lose power before calling fdatasync(), what's the worst that can happen on...say...Linux/ext3? Is there a standard that specifies this behavior more generally? I don't see anything like it in SUS.
More precise questions: Does my write necessarily happen in byte order (I'm guessing not)? Does each block have either all old bytes or all new bytes (unsure of this), and if so is there a way (preferably portable) to get the filesystem's blocksize (something pathconf()-like)? Does each byte have either all old bits or all new bits (I hope so)? Can bits get flipped that I didn't even change?
In a coffee shop, you're going to be transferring stuff exclusively over their crappy (maybe 512 kbps) Internet connection. I would be shocked if any software firewall were so inefficient as to take more than 1% CPU in that situation on a modern machine
Somehow I missed the middle of the article. They don't just do the normal firewall things - they also do a bunch of higher-level things (snort, HTTP antivirus proxy, etc.) which are more CPU-intensive. So I guess it might save significant CPU usage over doing this on the host processor. It's debatable whether it's worth doing on any processor...
Why would anyone want this? Well, a router that combines firewall, nat, vpn, etc. is fine for home use, but what about the coffee shop? For a mobile computer having a on-computer firewall is a must. As far as why anybody would choose to use this over any software firewall... I can only assume it's for people who don't want yet another piece of software hogging their cpu. Most software firewalls aren't that intensive, but if you're looking to free up that 3-5% of your resources, hardware is the way to do it. Of course, without a benchmark showing a difference, the actual performance increase is lost in the market speak.
In a coffee shop, you're going to be transferring stuff exclusively over their crappy (maybe 512 kbps) Internet connection. I would be shocked if any software firewall were so inefficient as to take more than 1% CPU in that situation on a modern machine. Even the device's maximum speed (100 Mbps) isn't that intensive (I use gigabit Ethernet), and firewalling's not the most CPU-intensive part of networking unless most of your inbound packets are getting dropped by the firewall.
leather_helmet suggested another reason:
Yes, there are software solutions etc. but having a dongle that I can take from one machine to another would be awesome - Potentially I no longer have to install firewalls on each and every computer that I use
Well, that's not true either. You need to install the driver for this machine onto each machine or it does nothing. That differentiates it from their earlier product, which actually had a pair of Ethernet ports - no driver required. (No wireless support, though.)
This device is useless:
mobile/coffee shop use - it costs $180 instead of $0, can save maybe 1% CPU, is no more secure than a software firewall, and is less convenient (driver setup, custom configuration software, and physically you have to keep plugging the dongle in every time you pull your laptop out of the case)
fixed use - costs $180 instead of $40 for a much more capable dedicated machine, not as convenient (driver setup - ergh)
There is nothing wrong with explaining how scientists interpret data. The data themselves only give part of the picture, especially to non-scientists who don't know as much about the issues.
It helps to look at all of the data. In each case you listed, it would be wild speculation at best to reject the "implied conclusion" in favor of the "interpretation", unless you did so based on more "raw data" that you presented. How do you know that CO2 causes additional temperature increases? How do you know there was a brief spike in volcanism? How do you know the increase in solar intensity is insignificant? These are key questions - good scientists don't look at fixed data sets and choose interpretations to rationalize the conclusions they've already made. Instead, they come up with ideas, use them to design calculations/experiments and predictions, carry through, examine the result, and repeat.
That said, it's unrealistic to expect people to properly analyze all the data on climate change in the half hour or less they spend in the exhibit. The best approach in presenting science to the public is to give people a taste of the process (some evidence with the best present analysis, maybe some history of the field, maybe walk them through devising a simple experiment), an idea of where to learn more (maybe books in the gift shop), and also the result. That result is what most scientists currently believe, with their stated level of confidence. ("Result" isn't quite the right word, since it can change, but it will have to do.)
Hey, who modded the parent flamebait? It's a reasonable question which should be answered instead of downmodded.
Why not just abolish the electoral college system in general?
In effect, they're trying that, but without amending the Constitution. (I don't think it will do anything, though. The swing states like the special attention they get, and so I doubt they'll ever follow Maryland's lead. Maryland knows this, so the bill must be symbolic.)
Or, better yet, have the electoral votes be cast in the same ration as the popular vote in the state.
The way they've proposed guarantees that if the bill takes effect, the popular vote will win every time. Your system doesn't. Imagine if states responsible for 270 electoral votes adopted such a system (smallest point at which it takes effect) and those responsible for the remaining 269 didn't. Then say there's an election and popular vote is 60% Democrat / 40% Republican. Under the system they've proposed, the majority of electoral votes go to the popular vote winner => the popular vote wins every time. Under your proposed system, 162/270 votes go the Democrats. They also need to win the vote in states responsible for 108 out of the remaining 269. If more blue states than red states were to adopt your scheme, it could cause Republicans to win in a case where Democrats would have won on the old system or by the popular vote. Maryland doesn't want that.
Or worse: say they adopt your scheme without requiring like action from other states for it to take effect. That might make Republicans more likely to campaign in what was formerly considered a blue state (making things more interesting), but...again with the 60/40 scenario, they'd be saying they want Maryland voters' aggregate decision to be worth 40% less than everyone else's. As that decision is usually in favor of Democrats and (not coincidentally) Democrats are the ones making this bill, their own party would lynch them for doing that.
I am a Verizon Wireless customer. My contract is long since up, and I would like to switch to a cell phone carrier which does not believe it has any right to disclose my phone records to any third party, except the government when specifically requested by subpoena.
But...which carrier would that be? If I remember correctly from the first reports, Qwest was the only phone company which refused to do this. But...well, their wireless coverage is awful, near my current area (San Francisco Bay Area), back home (Iowa, where Qwest is the major phone company!), and elsewhere. While the most private conversation is the one I never have, I don't want to go to the extreme of not being able to make or receive calls. Is there another option? A major carrier which either never disclosed phone records improperly or has stopped doing so?
It's stupid that there are magical filenames in the form of UUIDs that cause Explorer to load and run arbitrary DLLs.... They should have simply got rid of the magic naming system in favor of something explicit, such as a Shell Extension Interface that a shell extension must fully implement.
It sounds like they tried to do that, but he said: "As we saw earlier, lots of people mess up IUnknown::QueryInterface". I'm not familiar with Windows or COM, but I take that to mean that the way they find out what interfaces an object implements is to...well, load and run arbitrary DLLs, as you say, then ask the class what interfaces it supports. They must have some central registry of class IDs to their locations on the filesystem, not one specific to shell extensions.
They could include in that registry the supported interfaces of each class and only load as shell extensions classes which explicitly list that interface, but...they'd lose backward compatibility. That's a show-stopper to Microsoft. So no matter how stupid we might think the interface is, they're stuck with it and have to hack to make it work as best as they can. (From what I understand, that happens a lot in the Windows world.)
To me, the lesson is this: either be willing to undo all your previous decisions (screw backward compatibility - not a popular decision with third parties using your interfaces!) or always get it right from the beginning, perfectly anticipating all changes over the lifetime of your decision (not an easy thing to do). Linux seems to basically choose the first path, and Windows...well...I guess they're trying to take the second path, but it seems like they've screwed up many times before and still are paying for it.
Slashdot Mirror
Ahh. I did not see the difference between the two systems because I gave you far too much credit and stopped reading after the first paragraph or so. Now I understand. TAI is (despite a few caveats) an implementable solution to a real problem, while your idea is not.
Let's imagine that we've designed this "solar positioning system" and it works. Combined with the existing global positioning system, we now have a way (on machines with correct instrumentation, favorable atmospheric conditions, etc) to determine current position in the solar system (with some uncertainty). By the existing global positioning system, I know my current position on the earth (with some uncertainty). On a good day, when everything is working, of course. I'll be generous and assume for the sake of argument that today is the day it works, and that the precision is infinite. Given this, I can calculate the earth's current position relative to the sun.
This really doesn't solve the problem of how to convert an arbitrary number of seconds since some epoch (in a particular reference frame) into its equivalent calendar time on Earth, much less an arbitrary planet. For that, it is not enough to know earth's position relative to the sun. It is also necessary to know where the earth has been relative to the sun, for we define dates in terms of rotations completed, not absolute position. In the case of future dates, we also need to know where the earth will be relative to the sun. This last bit is an unsolved problem. All the king's horses and all the king's men have tried it, and the best they can do is tell us where to stick leap seconds with six months' notice. Now, while every machine could attempt to duplicate this effort, I fail to see the point. Distributing the leap second table - rather distributing the entire computational model and attempting to regather the current data on each machine - is simpler, does not require distributing esoteric hardware everywhere or launching solar satellites, can be used everywhere (even where reception is bad), is computationally feasible, uses less bandwidth, is vastly more reliable, and achieves consistent results between machines.
The computer time system you've just described is known as TAI. There are some catches, though. In particular, leap seconds are only guaranteed to be posted six months out, so you can only convert TAI<->UTC for times up to six months after your last download. That has a bunch of consequences:
In most cases, it's probably not a big deal if something a year out is a couple seconds off, but every now and then someone really cares.
I don't understand your comparison. Vonage customers pay a conventional ISP (say, Verizon) for broadband service (e.g. DSL). Are you saying that the government is forcing phone companies to sell DSL at below cost? Please share details, because I'm not getting that deal. Is it only available to Vonage customers? I'll sign up right now.
(Moderators, if cdrguru does not post a verifiable answer to my question, please mark the parent as a troll.)
Be careful there. I don't know the situation in Madagascar, but let me relay a story I heard which is possibly relevant:
In East Africa, Peace Corps volunteers wanted to improve the design of the huts the Masai would build. They taught them to incorporate a large vent, eliminating the smoke build-up. Worked beautifully, at least until malaria went totally out of control. Apparently the smoke kept the mosquitos out, so the pre-Peace Corps design was a reasonable compromise - lung diseases are preferable to malaria.
You may not want to make this change without other anti-mosquito or anti-malarial precautions. Googling finds a paper on the subject: Smoke and malaria: are interventions to reduce exposure to indoor air pollution likely to increase exposure to mosquitoes?. Probably worth reading if you haven't already.
"All the proprietary RH stuff" is just some trademarked logos and occurrences of the literal string "RedHat". That's about the only difference between RHEL and CentOS.
The Linux-Watch article you linked to doesn't make sense, either:
If they'd done even the slightest bit of research, they could have compared that to RedHat's claims of seven years of maintenance. If they wanted to do actual journalism, they would have pressed Oracle for specific examples of times RedHat has fallen through on that promise and (if they'd given any) seen what RedHat has to say in their defense. As far as I've seen, RedHat's support is as good as advertised.
I'd say there's a clear winner there. I don't think anyone thought RFC 2817 through. It suggests (though does not require) sending the initial request in plaintext (ugh), and there's no good mechanism to advertise the server support without penalty on first hit to a https URL (i.e., advertise in the URL or DNS records). Since no existing servers support it, this means for browsers to take advantage of it, they'd have to connect to existing servers on the http port, discover the lack of support, then fall back to normal https. So all sessions to existing https sites would be slowed down by at least two round trips (c->s SYN, s->c SYN/ACK, c->s request, s->c failure), or say 150 ms. I'll pass.
RFC 4366 is much better. No speed penalty - there's no need to advertise server support - the client can always send the option. The server ignores it if it doesn't understand, so without server support the status quo is maintained - the server admins shouldn't put more than one vhost on the same IP until they upgrade. When the client and server both support it, everything works fine. When the client doesn't support it, there's a security warning - about as good a failure mode as you're going to get with a protocol upgrade like this. And the client support is already there in the latest versions of Internet Explorer, Firefox, Safari, and Opera.
I think the Apache people are waiting on OpenSSL 0.9.9. bug 34607 (copy'n'paste the URL; don't follow the referral from slashdot) has a patch with support, but it is not effective without OpenSSL 0.9.9. I'm looking forward to it myself...tempted to install a development build just to have this feature, but probably not a good idea to use untested security software.
Exercise and diet always cut it, unless your girlfriend was a perpetual motion machine. According to this chart, walking at 3.0 mph for a 190-pound person burns 300 calories per hour. Four 6.2 mile trips at 3.0 mph is 8.3 hours of walking, or 2,500 calories. She might have been an unusually efficient walker, but there are limits, and she did other things in the day. If what you said was true (and I doubt it...eight hours of walking? really?), she ate more than 2,000 calories a day. You may not have seen her do it, but she somehow managed to cram in a lot of eating in the time between school, sex, eight hours of walking, homework, and sleeping.
An AC said further:
No. In fact, it's not merely implausible, but actually impossible. Your belief system is thermodynamically unsound.
You're setting the bar too high. I'm impressed that they correctly used the word "wont".
Still an unbelievably bad idea to use getpid() as a source of randomness. Portability and readability aside, it reminds me of this xkcd comic:
However random the method for generating the pid was, it's only chosen once over the lifetime of the process. So how many times does qmail use the same random number?
To rephrase only slightly, if it just needs cleanup, then it should be cleaned up? Well, yes, but you haven't said anything that's not obvious.
I'd say the real question is always "is the design right?". When I've worked with big chunks of existing code, I've rewritten it in only when there's an aspect of the design that's totally wrong and has infested nearly every line. Off-hand, I can only think of two classes of such mistakes:
Otherwise I've refactored - eliminated duplicate code, reorganized to fix broken abstractions, removed unnecessary overengineered design patterns, fixed function names, added comments, switched libraries, corrected error handling, fixed bugs in general, etc.
How is that possible? They are only selling in the US, correct? The population of the US is 300 million. Of that, I'm going to say only the 20- to 64-year-old group is at all likely to buy an iPhone. That's 180 million people, according to Wikipedia. Are one out of 180 working-aged Americans really standing in line to buy an iPhone in the first week?
I've been there as well, and that's not quite my impression. I stayed a couple nights at a house in Karen. There were fences and dogs, yes. (Big dogs, but not the kind that would tear an intruder to shreds. More the kind you'd have on a farm anywhere in the world.) No alarms or barbed wire, though there might have been if a nearby military base didn't make it largely unnecessary. However, my hosts told me that was more to prevent theft than violent crime.
We went through poorer (supposedly insanely dangerous) areas as well - my host took us along in a Land Cruiser as he looked for car parts in the Industrial City, and my friends and I biked through Dagoretti Market on our way out of town. Again, our hosts warned us about theft but told us we'd be safe enough. And we made it. There was one guy who yelled obscenities as we went by, but almost everyone was friendly and curious about the three wuzungu with fancy bicycles. (Actually, that held for my entire trip through Kenya and Tanzania, which was rather off the beaten path.) In fact, we saw a lot of genuine hospitality and kindness.
As for the armed policemen...yeah, I saw those, too, and I heard stories of widespread small-scale corruption. My host described a typical one: a policemen told another guy he needed to pay some ridiculous made-up-fine. The other guy let the policemen talk himself out, handed him half the claimed fine in cash, said "fuck off and go have lunch", and drove away.
I agree. You could make a fair argument that they never released the full source code, as the hardware specification should be included.
Definitely. Having a high-quality open source drivers is not just about having 3D support. As is, there's simply a choice between a mostly-good proprietary driver and a horrible, incomplete open source driver.
"nv" driver does not support all cards, has bad artifacts on my GeForce 6150, and fails to use DVI on large video modes with "NV(0): Mode "1920x1200" is larger than BIOS programmed panel size of 1280 x 1024. Removing.". (See bug 3654.) The nvidia people on the bug (look at the email addresses) said that they couldn't fix it with any but the latest GPU. That's obviously false...the proprietary drivers work fine.
nVidia won't fix the open source driver or give anyone else the information to do so, so a reverse-engineering effort is necessary.
I've read those, but they don't really help. They're focused on metadata, and I want to know what guarantees I have for data.
If it really is that quick and easy, then I agree. Definitely put them everywhere, though - no one would say one power outlet per room is enough, so I'm not sure why you'd say such a thing for a network drop either.
Wikipedia doesn't mention such a cable. Do you mean category 5e? category 6? category 6a? The last is what I'd suggest, as apparently it will be needed for 10 Gigabit Ethernet. Seems to be pricey, but probably less than snaking new cables through everywhere or tearing apart walls.
I say put in generous amounts of category 6a anywhere you might want a computer or television (more than one per room, especially to prevent things like patch cables running around doorways) and coax where you might want TVs, but consider also adding fiber. Gigabit Ethernet won't be considered fast forever; soon you'll want 10 GbE, then 100 GbE, and so on. What is the limit of category 5e? category 6? category 6a? What is the limit of multi-mode fiber for your distances? single-mode fiber? How much extra would it cost to put in more/better cable before the walls are finished? How much extra would it cost to put in more/better cable afterward?
I was with you in the first paragraph. I expected you to lead up to "high-performance applications need a barrier - ensure operations this process performed before the barrier hit disk before operations it performs after the barrier()". Or for even higher performance, a more precise barrier that takes inodes or file descriptors: "the operations performed before on inode A hit disk before the operations performed after the barrier on inode B if a call to". I don't quite understand you leap to a transaction API. It seems useful (it would be cool to have full ACID on filesystem operations, even ones that span multiple files) but I'm not sure it's the way to get the best performance.
By the way, you seem knowledgeable on filesystem semantics. I've been wondering something for a while, and I haven't had luck googling the answer. If I call write() on a section of a file and then lose power before calling fdatasync(), what's the worst that can happen on...say...Linux/ext3? Is there a standard that specifies this behavior more generally? I don't see anything like it in SUS.
More precise questions: Does my write necessarily happen in byte order (I'm guessing not)? Does each block have either all old bytes or all new bytes (unsure of this), and if so is there a way (preferably portable) to get the filesystem's blocksize (something pathconf()-like)? Does each byte have either all old bits or all new bits (I hope so)? Can bits get flipped that I didn't even change?
Somehow I missed the middle of the article. They don't just do the normal firewall things - they also do a bunch of higher-level things (snort, HTTP antivirus proxy, etc.) which are more CPU-intensive. So I guess it might save significant CPU usage over doing this on the host processor. It's debatable whether it's worth doing on any processor...
In a coffee shop, you're going to be transferring stuff exclusively over their crappy (maybe 512 kbps) Internet connection. I would be shocked if any software firewall were so inefficient as to take more than 1% CPU in that situation on a modern machine. Even the device's maximum speed (100 Mbps) isn't that intensive (I use gigabit Ethernet), and firewalling's not the most CPU-intensive part of networking unless most of your inbound packets are getting dropped by the firewall.
leather_helmet suggested another reason:
Well, that's not true either. You need to install the driver for this machine onto each machine or it does nothing. That differentiates it from their earlier product, which actually had a pair of Ethernet ports - no driver required. (No wireless support, though.)
This device is useless:
It helps to look at all of the data. In each case you listed, it would be wild speculation at best to reject the "implied conclusion" in favor of the "interpretation", unless you did so based on more "raw data" that you presented. How do you know that CO2 causes additional temperature increases? How do you know there was a brief spike in volcanism? How do you know the increase in solar intensity is insignificant? These are key questions - good scientists don't look at fixed data sets and choose interpretations to rationalize the conclusions they've already made. Instead, they come up with ideas, use them to design calculations/experiments and predictions, carry through, examine the result, and repeat.
That said, it's unrealistic to expect people to properly analyze all the data on climate change in the half hour or less they spend in the exhibit. The best approach in presenting science to the public is to give people a taste of the process (some evidence with the best present analysis, maybe some history of the field, maybe walk them through devising a simple experiment), an idea of where to learn more (maybe books in the gift shop), and also the result. That result is what most scientists currently believe, with their stated level of confidence. ("Result" isn't quite the right word, since it can change, but it will have to do.)
Hey, who modded the parent flamebait? It's a reasonable question which should be answered instead of downmodded.
In effect, they're trying that, but without amending the Constitution. (I don't think it will do anything, though. The swing states like the special attention they get, and so I doubt they'll ever follow Maryland's lead. Maryland knows this, so the bill must be symbolic.)
The way they've proposed guarantees that if the bill takes effect, the popular vote will win every time. Your system doesn't. Imagine if states responsible for 270 electoral votes adopted such a system (smallest point at which it takes effect) and those responsible for the remaining 269 didn't. Then say there's an election and popular vote is 60% Democrat / 40% Republican. Under the system they've proposed, the majority of electoral votes go to the popular vote winner => the popular vote wins every time. Under your proposed system, 162/270 votes go the Democrats. They also need to win the vote in states responsible for 108 out of the remaining 269. If more blue states than red states were to adopt your scheme, it could cause Republicans to win in a case where Democrats would have won on the old system or by the popular vote. Maryland doesn't want that.
Or worse: say they adopt your scheme without requiring like action from other states for it to take effect. That might make Republicans more likely to campaign in what was formerly considered a blue state (making things more interesting), but...again with the 60/40 scenario, they'd be saying they want Maryland voters' aggregate decision to be worth 40% less than everyone else's. As that decision is usually in favor of Democrats and (not coincidentally) Democrats are the ones making this bill, their own party would lynch them for doing that.
I am a Verizon Wireless customer. My contract is long since up, and I would like to switch to a cell phone carrier which does not believe it has any right to disclose my phone records to any third party, except the government when specifically requested by subpoena.
But...which carrier would that be? If I remember correctly from the first reports, Qwest was the only phone company which refused to do this. But...well, their wireless coverage is awful, near my current area (San Francisco Bay Area), back home (Iowa, where Qwest is the major phone company!), and elsewhere. While the most private conversation is the one I never have, I don't want to go to the extreme of not being able to make or receive calls. Is there another option? A major carrier which either never disclosed phone records improperly or has stopped doing so?
It sounds like they tried to do that, but he said: "As we saw earlier, lots of people mess up IUnknown::QueryInterface". I'm not familiar with Windows or COM, but I take that to mean that the way they find out what interfaces an object implements is to...well, load and run arbitrary DLLs, as you say, then ask the class what interfaces it supports. They must have some central registry of class IDs to their locations on the filesystem, not one specific to shell extensions.
They could include in that registry the supported interfaces of each class and only load as shell extensions classes which explicitly list that interface, but...they'd lose backward compatibility. That's a show-stopper to Microsoft. So no matter how stupid we might think the interface is, they're stuck with it and have to hack to make it work as best as they can. (From what I understand, that happens a lot in the Windows world.)
To me, the lesson is this: either be willing to undo all your previous decisions (screw backward compatibility - not a popular decision with third parties using your interfaces!) or always get it right from the beginning, perfectly anticipating all changes over the lifetime of your decision (not an easy thing to do). Linux seems to basically choose the first path, and Windows...well...I guess they're trying to take the second path, but it seems like they've screwed up many times before and still are paying for it.