When you use a credit or debit card at an ATM or in a store, a good chunk of those transactions now go through the internet. In 1995, they all dialed up/used leased lines to a packet switched network (DATAPAC, TYMNET, etc.) or a terminal bank. Your hypothetical Sally/Sam the Wallmart Greeter who doesn't use the internet works at a store where ordering, inventory, POS and other essential activities require an Internet connection.
Modems are/were rated in actual bits in decimal with no base-2/base-10 shenanigans. So 56k was actually 56000... Or more then likely you actually got 44000.
2450DPI on an inkjet printer is almost always a marketing number. Usually, they consider the dyes/inks separately. The paper itself can't deal with points that far either. The purpose of having higher DPIs on a printer is:
(a) Marketing. (b) Reducing the visibility of the pixel artifacts (i.e.: supersample, blur, spray on the paper).
1) It's impossible to successfully compile anything complex with 64-bit compiler flags (i.e.: -arch x86_64 -m64) since all libraries will be built without said flags... So you have to manually figure out all the dependencies yourself or backtrack the 32-bit install piecemeal.
2) X11 is/was often broken and needed XFree86 compiled instead of Apple's X11. This might have been dealt with in all cases now.
3) They are hopelessly behind every major O/S release. It took forever to have a 10.5 compatible fink and/or macport that was officially released.
All in all, I had to build a 64-bit application chain for 10.5/Intel and it took me two days to get ~30 packages compiled and linked successfully and fink/macport couldn't be used. I often had to reverse engineer fink mac patches for the packages that it did have, it's silly that I couldn't use fink to build them in 64-bit!
The rationale for a 64-bit build was a 40% performance improvement.
Yes because you calling your grandmother to chit chat using VoIP is far more important than me sending Magnetic Resonance Imaging files to India via FTP.
If you need guaranteed bandwidth, you buy it. We receive hundreds of MRIs per months at work and we don't have a residential DSL. We have an optical fiber link (GigE) with an ultimate "Internet" (for what it's worth in a BGP world) link around 300mbps 95-percentile. Guess what, we get our contracted bandwidth... All the time. It's not exactly cheap though, but then we're not downloading porn torrents...
Certificates are all about encryption. Places I can sniff your packets from:
[snip]
No, SSL is about encryption. A certificate is merely a signed public key. Of course you could hijack a session and insert your own certificate in there, but then you'd have to have a CA authority sign it or my browser will throw a fit. And that's why trust is the only thing that matters in SSL. Alice doesn't know Bob, so Alice can't trust Bob to not be Emily.
The problem with SSL certificate is that what you're supposed to be buying is trust. Your 400$ is supposed to be for VeriSign to validate that (a) an entity of that name/address pair exist; and (b) there's supporting evidence that the applicant represents that entity.
The reiterate strongly: Certificates are about authentication not encryption!
This isn't cheap, it requires a fair bit of effort.
Also, the CA needs to be trusted in the first place. That's very gray, but even old VeriSign is a lot more trustworthy then "Joe Q. Random Computer Service Associates" with a PO Box in RU.
Most proponent of "free" CAs really want the little padlock without any concern about trust because they implicitly trust themselves. Suppose you did have a shall-issue free-for-all CA on the web. What value would you place on its certificates? Would you trust that entity to not have a compromised private key?
At the risk of being modded troll, OO Calc will probably never replace Excel - other than Suns and big iron, corporate america runs on Microsoft Excel (not necessarily a good thing, but still).
When you were still a wet in the ear young one, corporate america ran on Lotus 1-2-3 and nothing was ever supposed to upset that either...
I don't think OO calc is the software to do it, but early Excel was a joke so who knows what will be the standard in a decade.
A modern SSD is able to handle write intensive database application with reliability on par with HDDs. The SSD logic spreads the writes around the disk to prevent premature wear so a record updated a million times might well never be written twice over any given flash cells. And even at 512 bytes each, there's 195 millions of them on a 100GB SSD. Each of which has about a 1 million cycle life and there's normally spare cells to handle failures. I'll take that over a SCSI disk.
Not only does wear leveling on very large (> 100 GB) completely moot the point *even* with 100000 cycle life, but modern high-capacity flash has cycle life in the millions of cycles, they have extra capacity set aside to deal with cell failures, they have error correction/detection, they have wear leveling. We're a long way off using FAT16 on straight 128 megabits flash chips...
I don't know why everyone keeps repeating flash "problems" from the mid/late 90s. We're in 2008, flash has been widely used in huge quantities for well over a decade with thousands of engineers applying well understood solutions to the problems.
Engineering school tends to weed out idiots. That leaves a pool with a higher probability of pulling off the complex "make bomb, plant it and destroy things" process. Plus, they might be smart enough that they don't have to blow themselves up while doing it!
Funnily enough, this has been par for the course at Microsoft for a while. The old Windows 95 upgrade version only checked that a file "C:\WIN31\WIN.COM" existed and then it would merrily "upgrade".
Why not anycast a bunch of distributed ad servers like some of the DNS root-servers? ISPs might well volunteer some rackspace at their main hubs to reduce backbone bandwith usage and increase customer satisfaction all in one go...
If you're going to be backpacking, everything you need will travel on your back (or front if you bring too much stuff for the backpack). So those 10-12lbs of electronic you're thinking of bringing are going to be easily a third of the weight you lug around.
But wait! It gets worse. You'll want to leave them somewhere during the days. If you stick to fancy hotels, no problems. In hostels and el-cheapo places you'll want to be very careful especially in large dorms with high turnover. So why bring the headache? Find what's the least you can get away with and only bring that.
I speak from experience, I did the same thing a few years ago. My laptop was a thinkpad X series with a BSD O/S on it. Pretty light at 3.2lbs. The power was no big deal, the adapter took 100-240 @ 50/60hz I got the wall cable for 5€ in a random computer shop/repair place in Brussels. The laptop was convenient for dumping my CF cards (I had a 32M card wth a 1.3MP camera) or at least that's what I thought at first. After about 4 weeks, I realized that I didn't use it nearly as much as I thought I would. That my bag was heavy. That I had to be constantly worried about something else then my passport and wallet. I sent the whole thing to my folks back home through surface mail and never regretted it (along with a bunch of other things I didn't want to carry for another 6 weeks).
I guess the bottomline is don't bring it unless it's absolutely essential. If it's essential bring the cheapest/simplest device that will do the job. Sending stuff back by surface mail is a good way to prune stuff you don't want to lug around (think souvenirs and copies of your pictures on CD).
As a final thing, throughout the "first world" just about anything you truly miss can be procured locally at decent price.
Funnily enough, the AT&T Daytona RDBMS is basically implemented at gzipped (or similar) compressed text files searched with grep. Of course there's some differences with normal grep: queries are compiled to regexp and then compiled to an optimized C program representing the optimal grep-like tool for the specific query. It is then parallelized on an HP superdome.
Also, most RDBMS implement linear search which is grep like. The use of the LIKE statement is even closer to grep and let's not forget that many RDBMS like PostgreSQL support using regexp in lieu of LIKE statements...
Stop and go traffic -- Electric motors don't consume electricity unless they are moving the car. Only the accessories would use up electricity. The brakes would actually feed back into the battery so not a major worry. Fuel usage per unit of time would be drastically lower then a conventional car which has to maintain minimum idle speed and still burn fixed amount of gas per revolution. The ICE is designed to "charge the battery fully while maintaining a cruise control speed of 70mph", given the vehicle is stationnary full recharge would probably be 20 minutes or less, net decrease on fuel consumption to recharge the battery pack since the ICE operates at a constant 1800 rpm and so fuel consumption is only affected by temperature/humidity.
Errands -- Short distances is precisely where hybrids shine.
Diminishing battery capacity over time -- This is dependant on battery technology employed. It looks like GM is using Li-Ion batteries. Real world usage will show what can be expected here. Good point however.
Detours -- I don't see the issue. If the detour causes the commute to go above the 40 miles (or whatever effective range the specific driving conditions dictate) the ICE kicks in. Not a major issue beyond a drop in usable power (from a peak of 136kW to a possible low of 71kW at full discharge.)
Carpooling -- Sure, more weight increases energy consumption but it decreases the number of vehicle on the road correspondingly. The car likely weighs around 2000-2500lbs to begin with so if 4 adults bump the car to 2800-3300lbs energy economy will suffer. Not anymore or any less then a gasoline vehicle given equivalent passenger load. On the freeway this will likely not be very significant. In stop and go traffic, the energy cost of starting will be higher. However electrical motors always produce peak torque at all RPMs so they would actually be more efficient then comparable gasoline vehicle.
Anyone else have to drive to lunch? -- So? When the battery are low, the ICE kicks in. Effective range is suppowsed to be over 600 miles on one 13 gallons tank on the highway.
As for acceleration, a given maximum power output (136kW here) will only accelerate a car of a given mass at a certain rate. For this car it appears to take 8 seconds to reach 60 mph. A 136kW gas engine would take a bit more time because of the power loss to the transmission and because peak power output is only at optimal RPM and not constant through the entire power range of the engine.
[...], it was the first dynamic web server technology that used a multithreaded model in addition to runtime-compiled code (bye-bye CGI),[...].
The fact that you don't know about FastCGI (or AOLserver for that matter) doesn't mean that the above statements is true. AOLServer has been around for a long time and while TCL is not sexy, it was a multi-threaded application server (I don't know if the individual TCL application threads could access data from the other threads, but there was no forking.)
FastCGI transforms CGIs from "exec this file" to "connect to this socket". FastCGI has been around since at least may 1996. It was designed for "long lived application servers"...
Inmarsat is mandated has a ship-to-shore communication system for distress signaling purpose. Along with a specially enabled VHF radio and a GPS (I believe a 406EPIRB is also required), it forms part of the GMDSS (Global Marine Distress something something).
Inmarsat has basically taken the place used by a traditional HF radio. It should be noted that it's not that expensive if it is used solely has part of the GMDSS requirements. The pricing model on Inmarsat is a bit extortionary, but they don't really have much competition.
Corporations vs. The World
on
Do You Code Sign?
·
· Score: 2, Insightful
You work for a corporation. You have some control over a bunch of desktops. You have an hopefully security aware groups to vet things and inspect and what not. You're the ONLY group of users who see real benefits to code signing. Of course it all works, FROM YOUR POINT OF VIEW. (sorry for shouting).
Me, I'm just one guy. I'm not going to do due diligence for every software out there. Half of what I use isn't signed. Should I just give up on it? I don't have TIME to deal with security enough to make a whitelist useful.
Them over there, they're also a big corporation, but they have tons of sites and while people back at HQ are somewhat clueful, the support folks at the site in the Boondocks halfway around the country suck. Or security is just not a priority, whatever. Benefits from code signing? Nil.
So you, the poster of this article, are in the one group that actually gains anything. I would recommend you investigate the possibility of resigning absolutely everything and banning anything but your own cert, not even microsoft's. Cause it sure seems like you run a tight ship, I envy you.
Slashdot Mirror
When you use a credit or debit card at an ATM or in a store, a good chunk of those transactions now go through the internet. In 1995, they all dialed up/used leased lines to a packet switched network (DATAPAC, TYMNET, etc.) or a terminal bank. Your hypothetical Sally/Sam the Wallmart Greeter who doesn't use the internet works at a store where ordering, inventory, POS and other essential activities require an Internet connection.
Actually, no.
Modems are/were rated in actual bits in decimal with no base-2/base-10 shenanigans. So 56k was actually 56000... Or more then likely you actually got 44000.
http://www.nemertes.com/studies/internet_interrupted_why_architectural_limitations_will_fracture_net
Not nearly as bad as the Sunday Times article...
2450DPI on an inkjet printer is almost always a marketing number. Usually, they consider the dyes/inks separately. The paper itself can't deal with points that far either. The purpose of having higher DPIs on a printer is:
(a) Marketing.
(b) Reducing the visibility of the pixel artifacts (i.e.: supersample, blur, spray on the paper).
Specific special case. Basically large 3D matrices of doubles.
3D MRI registration using X-correllation as objective function as implemented by DL Collins et al. It's available as part of the MINC package.
Fink and MacPorts both have the same problems:
1) It's impossible to successfully compile anything complex with 64-bit compiler flags (i.e.: -arch x86_64 -m64) since all libraries will be built without said flags... So you have to manually figure out all the dependencies yourself or backtrack the 32-bit install piecemeal.
2) X11 is/was often broken and needed XFree86 compiled instead of Apple's X11. This might have been dealt with in all cases now.
3) They are hopelessly behind every major O/S release. It took forever to have a 10.5 compatible fink and/or macport that was officially released.
All in all, I had to build a 64-bit application chain for 10.5/Intel and it took me two days to get ~30 packages compiled and linked successfully and fink/macport couldn't be used. I often had to reverse engineer fink mac patches for the packages that it did have, it's silly that I couldn't use fink to build them in 64-bit!
The rationale for a 64-bit build was a 40% performance improvement.
Yes because you calling your grandmother to chit chat using VoIP is far more important than me sending Magnetic Resonance Imaging files to India via FTP.
If you need guaranteed bandwidth, you buy it. We receive hundreds of MRIs per months at work and we don't have a residential DSL. We have an optical fiber link (GigE) with an ultimate "Internet" (for what it's worth in a BGP world) link around 300mbps 95-percentile. Guess what, we get our contracted bandwidth... All the time. It's not exactly cheap though, but then we're not downloading porn torrents...
Yes! Well written use cases for missing feature are much much more likely to result in said new feature.
Certificates are all about encryption. Places I can sniff your packets from:
[snip]
No, SSL is about encryption. A certificate is merely a signed public key. Of course you could hijack a session and insert your own certificate in there, but then you'd have to have a CA authority sign it or my browser will throw a fit. And that's why trust is the only thing that matters in SSL. Alice doesn't know Bob, so Alice can't trust Bob to not be Emily.
The problem with SSL certificate is that what you're supposed to be buying is trust. Your 400$ is supposed to be for VeriSign to validate that (a) an entity of that name/address pair exist; and (b) there's supporting evidence that the applicant represents that entity.
The reiterate strongly: Certificates are about authentication not encryption!
This isn't cheap, it requires a fair bit of effort.
Also, the CA needs to be trusted in the first place. That's very gray, but even old VeriSign is a lot more trustworthy then "Joe Q. Random Computer Service Associates" with a PO Box in RU.
Most proponent of "free" CAs really want the little padlock without any concern about trust because they implicitly trust themselves. Suppose you did have a shall-issue free-for-all CA on the web. What value would you place on its certificates? Would you trust that entity to not have a compromised private key?
At the risk of being modded troll, OO Calc will probably never replace Excel - other than Suns and big iron, corporate america runs on Microsoft Excel (not necessarily a good thing, but still).
When you were still a wet in the ear young one, corporate america ran on Lotus 1-2-3 and nothing was ever supposed to upset that either...
I don't think OO calc is the software to do it, but early Excel was a joke so who knows what will be the standard in a decade.
FUD!
A modern SSD is able to handle write intensive database application with reliability on par with HDDs. The SSD logic spreads the writes around the disk to prevent premature wear so a record updated a million times might well never be written twice over any given flash cells. And even at 512 bytes each, there's 195 millions of them on a 100GB SSD. Each of which has about a 1 million cycle life and there's normally spare cells to handle failures. I'll take that over a SCSI disk.
Not only does wear leveling on very large (> 100 GB) completely moot the point *even* with 100000 cycle life, but modern high-capacity flash has cycle life in the millions of cycles, they have extra capacity set aside to deal with cell failures, they have error correction/detection, they have wear leveling. We're a long way off using FAT16 on straight 128 megabits flash chips...
I don't know why everyone keeps repeating flash "problems" from the mid/late 90s. We're in 2008, flash has been widely used in huge quantities for well over a decade with thousands of engineers applying well understood solutions to the problems.
Smart people make good terrorists, news at 11!
Engineering school tends to weed out idiots. That leaves a pool with a higher probability of pulling off the complex "make bomb, plant it and destroy things" process. Plus, they might be smart enough that they don't have to blow themselves up while doing it!
Funnily enough, this has been par for the course at Microsoft for a while. The old Windows 95 upgrade version only checked that a file "C:\WIN31\WIN.COM" existed and then it would merrily "upgrade".
Why not anycast a bunch of distributed ad servers like some of the DNS root-servers? ISPs might well volunteer some rackspace at their main hubs to reduce backbone bandwith usage and increase customer satisfaction all in one go...
If you're going to be backpacking, everything you need will travel on your back (or front if you bring too much stuff for the backpack). So those 10-12lbs of electronic you're thinking of bringing are going to be easily a third of the weight you lug around.
But wait! It gets worse. You'll want to leave them somewhere during the days. If you stick to fancy hotels, no problems. In hostels and el-cheapo places you'll want to be very careful especially in large dorms with high turnover. So why bring the headache? Find what's the least you can get away with and only bring that.
I speak from experience, I did the same thing a few years ago. My laptop was a thinkpad X series with a BSD O/S on it. Pretty light at 3.2lbs. The power was no big deal, the adapter took 100-240 @ 50/60hz I got the wall cable for 5€ in a random computer shop/repair place in Brussels. The laptop was convenient for dumping my CF cards (I had a 32M card wth a 1.3MP camera) or at least that's what I thought at first. After about 4 weeks, I realized that I didn't use it nearly as much as I thought I would. That my bag was heavy. That I had to be constantly worried about something else then my passport and wallet. I sent the whole thing to my folks back home through surface mail and never regretted it (along with a bunch of other things I didn't want to carry for another 6 weeks).
I guess the bottomline is don't bring it unless it's absolutely essential. If it's essential bring the cheapest/simplest device that will do the job. Sending stuff back by surface mail is a good way to prune stuff you don't want to lug around (think souvenirs and copies of your pictures on CD).
As a final thing, throughout the "first world" just about anything you truly miss can be procured locally at decent price.
Hmm, the Ford concept is battery powered with fuel cell to recharge the battery. Hydrogen must be provided from your local H2 fueling station....
Funnily enough, the AT&T Daytona RDBMS is basically implemented at gzipped (or similar) compressed text files searched with grep. Of course there's some differences with normal grep: queries are compiled to regexp and then compiled to an optimized C program representing the optimal grep-like tool for the specific query. It is then parallelized on an HP superdome.
Also, most RDBMS implement linear search which is grep like. The use of the LIKE statement is even closer to grep and let's not forget that many RDBMS like PostgreSQL support using regexp in lieu of LIKE statements...
The problems you cite:
Stop and go traffic -- Electric motors don't consume electricity unless they are moving the car. Only the accessories would use up electricity. The brakes would actually feed back into the battery so not a major worry. Fuel usage per unit of time would be drastically lower then a conventional car which has to maintain minimum idle speed and still burn fixed amount of gas per revolution. The ICE is designed to "charge the battery fully while maintaining a cruise control speed of 70mph", given the vehicle is stationnary full recharge would probably be 20 minutes or less, net decrease on fuel consumption to recharge the battery pack since the ICE operates at a constant 1800 rpm and so fuel consumption is only affected by temperature/humidity.
Errands -- Short distances is precisely where hybrids shine.
Diminishing battery capacity over time -- This is dependant on battery technology employed. It looks like GM is using Li-Ion batteries. Real world usage will show what can be expected here. Good point however.
Detours -- I don't see the issue. If the detour causes the commute to go above the 40 miles (or whatever effective range the specific driving conditions dictate) the ICE kicks in. Not a major issue beyond a drop in usable power (from a peak of 136kW to a possible low of 71kW at full discharge.)
Carpooling -- Sure, more weight increases energy consumption but it decreases the number of vehicle on the road correspondingly. The car likely weighs around 2000-2500lbs to begin with so if 4 adults bump the car to 2800-3300lbs energy economy will suffer. Not anymore or any less then a gasoline vehicle given equivalent passenger load. On the freeway this will likely not be very significant. In stop and go traffic, the energy cost of starting will be higher. However electrical motors always produce peak torque at all RPMs so they would actually be more efficient then comparable gasoline vehicle.
Anyone else have to drive to lunch? -- So? When the battery are low, the ICE kicks in. Effective range is suppowsed to be over 600 miles on one 13 gallons tank on the highway.
As for acceleration, a given maximum power output (136kW here) will only accelerate a car of a given mass at a certain rate. For this car it appears to take 8 seconds to reach 60 mph. A 136kW gas engine would take a bit more time because of the power loss to the transmission and because peak power output is only at optimal RPM and not constant through the entire power range of the engine.
No, they'll use a hardware raid chipset on the Xserve.
Inmarsat is mandated has a ship-to-shore communication system for distress signaling purpose. Along with a specially enabled VHF radio and a GPS (I believe a 406EPIRB is also required), it forms part of the GMDSS (Global Marine Distress something something).
Inmarsat has basically taken the place used by a traditional HF radio. It should be noted that it's not that expensive if it is used solely has part of the GMDSS requirements. The pricing model on Inmarsat is a bit extortionary, but they don't really have much competition.
You work for a corporation. You have some control over a bunch of desktops. You have an hopefully security aware groups to vet things and inspect and what not. You're the ONLY group of users who see real benefits to code signing. Of course it all works, FROM YOUR POINT OF VIEW. (sorry for shouting).
Me, I'm just one guy. I'm not going to do due diligence for every software out there. Half of what I use isn't signed. Should I just give up on it? I don't have TIME to deal with security enough to make a whitelist useful.
Them over there, they're also a big corporation, but they have tons of sites and while people back at HQ are somewhat clueful, the support folks at the site in the Boondocks halfway around the country suck. Or security is just not a priority, whatever. Benefits from code signing? Nil.
So you, the poster of this article, are in the one group that actually gains anything. I would recommend you investigate the possibility of resigning absolutely everything and banning anything but your own cert, not even microsoft's. Cause it sure seems like you run a tight ship, I envy you.