Why aren't the leases on internet addresses high enough to convince people to give them back? Price them at a buck a month, and if someone truly can afford to spend $16m a month on a class A, let them. Otherwise they will give them back really fast. What's wrong with a little capitalism?
Write people an extremely hefty fine if they are involved in an accident while texting. Make it easier to convict them on involuntary manslaughter charges if they were texting at the time they hit a pedestrian. If people can safely text, great. If not, punish them when they cause problems.
Speaking of which, on Android why does the very popular app "The Weather Channel" need "Services that cost you money: directly call phone numbers" because I sure don't see that functionality anywhere.
Let's see... Google gave all of their employees the G1 for Christmas of 2008, same happened with the Nexus One for Christmas of 2009. Maybe you should check back around Christmas time.
It's even easier than that. I'm pretty sure I've seen this idea mentioned before on Slashdot:
The best scheme that I've seen is to have loser pays, but with the addition that a side is only responsible for up to the amount they spent on their personal lawyer. This brings much more power to the little guy trying to defend a lawsuit, and also makes sure that the corporation can't bury him in an insane amount of fees in the case that he loses.
This also provides the incentive of "only spending as much as you need on a lawyer" and not a penny more.
Did you even read the summary? Realtek's signing keys were stolen. That's why Verisign revoked them. Putting the verification keys in hardware wouldn't fix this issue.
As a person who was completely obsessed with maintaining cell reception, I did a ton of testing of cell phones on Verizon. I can say that the Nokias were always the best at holding calls in fringe areas, even the models with internal antennas like the 6236i. All the Nokias I owned would actually gain very little signal strength (1-2db) by extending their antenna. I read that part of their design was to be able to use the external antenna internally or externally. 2nd best was usually Motorola. There were definitely times where other Verizon users had to borrow my phone to maintain a call. When Nokias were dropped by Verizon I would go pick up used ones as backups. All in all, I owned 1 3589i, 3 6015i, and a 6236i, every single candybar style Nokia that Verizon carried near the end.
Testing done by others on Sprint would place the Nokias as the best followed by Sanyo. This was confirmed by many users on howardforums and by an internal Sprint engineer that had access to call drop data.
When doing large scale automated apt-get update; apt-get upgrade tasks, ask what happens to apt-get/dpkg when a postinstall script fails, or there were file conflicts with another package. Yes, the machine never fetches updates again. Serious amounts of dpkg --configure -a, dpkg --purge --force-reinstreq, and apt-get -f install are required to even get it working again. Also don't ask what happens when a user wants to install a local package with dpkg -i that has a missing dependency. Yes it prints an error, but unknowingly to the user the package actually gets half installed and breaks the automated update jobs. Why isn't there a --force flag to prevent this from happening?
Yum and rpm have had these issues solved for years and years, why can't Debian fix it?
You do know why Google picked Dalvik/Java right? It should be pretty obvious. Not getting yourself locked into a specific processor arch is actually a HUGE plus.
Take it from the example of Windows Mobile which had to be natively compiled for a ton of different architectures.... MIPS, PPC, SH3, SH4, x86, leading abandoned code to just not work on certain platforms. And without the source code for each and every application, they couldn't be ported.
Currently Iphone, WIndows Mobile, Maemo, and any other non-VM based platform will soon also feel this hurt when the smartphone world switches processor architectures away from ARM to the new hotness just like it has done in the past.
Technically Google uses anonymous information from Android phones that can do wifi and gps, which was pretty obvious once my access point started registering a location soon after I picked up a Droid. I wouldn't be surprised if Apple was doing the same.
And after you purchase the filer head for $78,500, where are you going to put the drives? Netapp disk shelves aren't cheap. Just because a filer head can support 840 drives doesn't mean you purchased 840 drives worth of disk shelves.
It was my impression that Fedora was primarily used by people seeking a "stable and low maintenance" RPM-based distro that they don't have to pay for. I've only used it a bit (intranet server at a former employer) so I'm not in on the distro's culture, but that's the impression I've gotten from reading comments by its users and paying (some) attention to its development over the years.
There is no alternative namespace, there are merely alternate streams in a file - named locations for storing meta data. The file is right there in the filesystem, obvious to all. The file data may be a bit hidden, requiring normal Windows system calls to read (just like one uses normal Windows system calls to create alernate data streams), instead of Notepad. Oh, wait, you can read them with Notepad too. What a bunch of FUD.
Because as we all know, no security issues ever came out of the namespace differences between C:\Program Files\foo and C:\PROGRA~1\foo
Just another person who's dealt with Ubuntu in a large enterprise setting. I don't mean for these comments to be flamebait, but it may come off that way. I'd just like to see more attention put toward them.
1. Incomplete automated installer. You can do nearly anything from Redhat's kickstart, but working with d-i doing partitioning, especially more advanced lvm and software raid setup is nearly impossible without some custom scripting hacks outside of d-i. Also, don't even ask what happens when you have a usb disk (or even just a card reader) plugged into the machine at automated install time, guess what gets recognized as/dev/sda... Speaking of which, since Ubuntu has their own installer, they don't support, fix, or use d-i, which means a lot of the time you will run into other random d-i installation bugs.
2. Ldap/krb5 stability. It's quite obvious that Ubuntu doesn't put a priority on testing or stability patching any of this, and in large scale deployments it just falls over on the server and client side.
3. Nobody in the enterprise uses cds or dvds to install, everything is automated from PXE, which means creating a local mirror to install from. Guess how difficult it is to mirror the "pool" directory without also getting the packages from every other version of Ubuntu. Yes you could use a script that parses the Packages file and only downloads the packages you need, but that just leaves more room for errors. Why can't I just have a single directory I can rsync?
4. When doing large scale automated apt-get update; apt-get upgrade tasks, ask what happens to apt-get/dpkg when a postinstall script fails, or there were file conflicts. Yes, the machine never fetches updates again. dpkg --configure -a and dpkg --purge --force-reinstreq and apt-get -f install are your manual cleanup friends. Also don't ask what happens when a user wants to install a local package with dpkg -i. Yes it prints an error, but unknowingly to the user the package actually gets half installed and breaks the automated update jobs. Why isn't there a --force flag to prevent this from happening?
5. When patching packages, there's at least 8 different ways a diff could be included in the sources. Here's a incomplete list of a few different schemes I've found over the years: - Just drop the patches into patches/ - Just drop the patches into a non-standard patches/ directory - Drop the patches into patches/ and add it to 00list - Drop the patches into patches/ and manually patch the source yourself - Edit the rules file and add in the patches manually
They really needs to adopt a single patching format, rather than quilt, dpatch, dbs, cdbs, and a bunch of other minor ones.
The sad part about this, is nearly all of these issues also exist in upstream Debian. I'd love to see these get fixed. I'd like more choices that I can run in the enterprise.
I guess the handful of bugs that I found in CentOS and filed at http://bugzilla.redhat.com/ that were fixed must have been a dream. Redhat's bugzilla is a friendly place if you don't need handholding, and just need something fixed.
Of course you can always get support by purchasing a single RHEL license for a single RHEL instance that you run, while the rest of the machines run CentOS, which would still be cheaper than a sitewide support contract from Canonical.
You still have many options for support on CentOS, you just have to get a little creative.
Your math has so many flaws, I'm not even sure where to start.
If you're car was using 100-200hp constantly you'd be hard accelerating up to around a constant rate of about 120-160mph all the time.
Did you actually calculate out how much hp a car uses at a constant real-world speed? It's actually much closer to 10-30hp at freeway speeds all depending on air, tire and transmission resistance. There's many formulas around the internet for this. Pick your favorite.
Charging a car overnight connected to a 240 Volt charger is well within feasible.
Actually, there's much much much more than just Mountain View and Kirkland. Take a look at all the locations for the job reqs: http://www.google.com/jobs/
Aaaaah, it's always fun when someone brings up one of your old companies. What's funny is that almost all of the development team at ChainCast jumped and is now at NetCableTV. And I always complained about their use of ActiveX (which was going to die at the time due to spyware) and their choice of having a management node architecture instead of a straight network client cloud that could scale itself. I kept telling them they should just mod a pre-existing p2p program to create their entire architecture.
Focusing on the original problem of "my cell phone gets bad reception in my house on the mountain" why not purchase a phone that is known for really good reception?
I bought a Nokia phone specifically for it's reception abilities, and I've had many people on the same wireless carrier that couldn't use their phone in places that I could.
Pick up a Nokia 6010 (basic phone) or 6230 (if you need all the features) and see if that fixes your problem.
Why fix the problem with a few hundred thousand dollars when a $100 solution would work.
Slashdot Mirror
Why aren't the leases on internet addresses high enough to convince people to give them back? Price them at a buck a month, and if someone truly can afford to spend $16m a month on a class A, let them. Otherwise they will give them back really fast. What's wrong with a little capitalism?
Write people an extremely hefty fine if they are involved in an accident while texting. Make it easier to convict them on involuntary manslaughter charges if they were texting at the time they hit a pedestrian. If people can safely text, great. If not, punish them when they cause problems.
Because that obviously worked well for drunk driving? You know that 37% of all automobile fatalities still involve alcohol right? http://www.alcoholalert.com/drunk-driving-statistics.html
Sure that number may be down from previous years, but its still too high.
Speaking of which, on Android why does the very popular app "The Weather Channel" need "Services that cost you money: directly call phone numbers" because I sure don't see that functionality anywhere.
Let's see... Google gave all of their employees the G1 for Christmas of 2008, same happened with the Nexus One for Christmas of 2009. Maybe you should check back around Christmas time.
It's even easier than that. I'm pretty sure I've seen this idea mentioned before on Slashdot:
The best scheme that I've seen is to have loser pays, but with the addition that a side is only responsible for up to the amount they spent on their personal lawyer. This brings much more power to the little guy trying to defend a lawsuit, and also makes sure that the corporation can't bury him in an insane amount of fees in the case that he loses.
This also provides the incentive of "only spending as much as you need on a lawyer" and not a penny more.
Did you even read the summary? Realtek's signing keys were stolen. That's why Verisign revoked them. Putting the verification keys in hardware wouldn't fix this issue.
What about the average 30% iphone (2g-3g) dropped call rate in NY?
http://gizmodo.com/5370493/apple-genius-bar-iphones-30-percent-call-drop-is-normal-in-new-york
I would assume that iphones would have a higher drop rate than most other phones. But yes, your numbers could be dead on and are pretty disturbing.
As a person who was completely obsessed with maintaining cell reception, I did a ton of testing of cell phones on Verizon. I can say that the Nokias were always the best at holding calls in fringe areas, even the models with internal antennas like the 6236i. All the Nokias I owned would actually gain very little signal strength (1-2db) by extending their antenna. I read that part of their design was to be able to use the external antenna internally or externally. 2nd best was usually Motorola. There were definitely times where other Verizon users had to borrow my phone to maintain a call. When Nokias were dropped by Verizon I would go pick up used ones as backups. All in all, I owned 1 3589i, 3 6015i, and a 6236i, every single candybar style Nokia that Verizon carried near the end.
Testing done by others on Sprint would place the Nokias as the best followed by Sanyo. This was confirmed by many users on howardforums and by an internal Sprint engineer that had access to call drop data.
Not really scary.
You've never used Google maps mobile to dial a business directly?
Nearly all android apps access the phone state and identity, mostly to tell if you're in a call so they won't attempt to do microphone recording.
Any app that caches data needs to use the SD card.
Recording audio is actually quite important when you're doing a voice search.
Nothing to see here.
Because it's too difficult to quickly Google their release schedule which gives you upcoming notice of a release? https://wiki.mozilla.org/Releases
Speaking of issues with apt-get, my old comment:
When doing large scale automated apt-get update; apt-get upgrade tasks, ask what happens to apt-get/dpkg when a postinstall script fails, or there were file conflicts with another package. Yes, the machine never fetches updates again. Serious amounts of dpkg --configure -a, dpkg --purge --force-reinstreq, and apt-get -f install are required to even get it working again. Also don't ask what happens when a user wants to install a local package with dpkg -i that has a missing dependency. Yes it prints an error, but unknowingly to the user the package actually gets half installed and breaks the automated update jobs. Why isn't there a --force flag to prevent this from happening?
Yum and rpm have had these issues solved for years and years, why can't Debian fix it?
Google has that already. Any Android device, Chrome browser or Google Gears installation can already locate itself using that exact method. Try it.
You do know why Google picked Dalvik/Java right? It should be pretty obvious. Not getting yourself locked into a specific processor arch is actually a HUGE plus.
Take it from the example of Windows Mobile which had to be natively compiled for a ton of different architectures.... MIPS, PPC, SH3, SH4, x86, leading abandoned code to just not work on certain platforms. And without the source code for each and every application, they couldn't be ported.
Currently Iphone, WIndows Mobile, Maemo, and any other non-VM based platform will soon also feel this hurt when the smartphone world switches processor architectures away from ARM to the new hotness just like it has done in the past.
Google just engineered it to be smarter.
Technically Google uses anonymous information from Android phones that can do wifi and gps, which was pretty obvious once my access point started registering a location soon after I picked up a Droid. I wouldn't be surprised if Apple was doing the same.
I'm guessing you must not be familiar with the offline features of Google Gears which is included in Chrome:
http://www.techcrunch.com/2009/01/27/gmail-goes-offline-with-google-gears/
http://googledocs.blogspot.com/2008/03/bringing-cloud-with-you.html
And after you purchase the filer head for $78,500, where are you going to put the drives? Netapp disk shelves aren't cheap. Just because a filer head can support 840 drives doesn't mean you purchased 840 drives worth of disk shelves.
It was my impression that Fedora was primarily used by people seeking a "stable and low maintenance" RPM-based distro that they don't have to pay for. I've only used it a bit (intranet server at a former employer) so I'm not in on the distro's culture, but that's the impression I've gotten from reading comments by its users and paying (some) attention to its development over the years.
Nope, you would be thinking (or should be thinking) of CentOS http://www.centos.org/
There is no alternative namespace, there are merely alternate streams in a file - named locations for storing meta data. The file is right there in the filesystem, obvious to all. The file data may be a bit hidden, requiring normal Windows system calls to read (just like one uses normal Windows system calls to create alernate data streams), instead of Notepad. Oh, wait, you can read them with Notepad too. What a bunch of FUD.
Because as we all know, no security issues ever came out of the namespace differences between C:\Program Files\foo and C:\PROGRA~1\foo
http://www.cert.org/advisories/CA-1998-04.html
http://www.kb.cert.org/vuls/id/544392
Just another person who's dealt with Ubuntu in a large enterprise setting. I don't mean for these comments to be flamebait, but it may come off that way. I'd just like to see more attention put toward them.
1. Incomplete automated installer. You can do nearly anything from Redhat's kickstart, but working with d-i doing partitioning, especially more advanced lvm and software raid setup is nearly impossible without some custom scripting hacks outside of d-i. Also, don't even ask what happens when you have a usb disk (or even just a card reader) plugged into the machine at automated install time, guess what gets recognized as /dev/sda... Speaking of which, since Ubuntu has their own installer, they don't support, fix, or use d-i, which means a lot of the time you will run into other random d-i installation bugs.
2. Ldap/krb5 stability. It's quite obvious that Ubuntu doesn't put a priority on testing or stability patching any of this, and in large scale deployments it just falls over on the server and client side.
3. Nobody in the enterprise uses cds or dvds to install, everything is automated from PXE, which means creating a local mirror to install from. Guess how difficult it is to mirror the "pool" directory without also getting the packages from every other version of Ubuntu. Yes you could use a script that parses the Packages file and only downloads the packages you need, but that just leaves more room for errors. Why can't I just have a single directory I can rsync?
4. When doing large scale automated apt-get update; apt-get upgrade tasks, ask what happens to apt-get/dpkg when a postinstall script fails, or there were file conflicts. Yes, the machine never fetches updates again. dpkg --configure -a and dpkg --purge --force-reinstreq and apt-get -f install are your manual cleanup friends. Also don't ask what happens when a user wants to install a local package with dpkg -i. Yes it prints an error, but unknowingly to the user the package actually gets half installed and breaks the automated update jobs. Why isn't there a --force flag to prevent this from happening?
5. When patching packages, there's at least 8 different ways a diff could be included in the sources. Here's a incomplete list of a few different schemes I've found over the years:
- Just drop the patches into patches/
- Just drop the patches into a non-standard patches/ directory
- Drop the patches into patches/ and add it to 00list
- Drop the patches into patches/ and manually patch the source yourself
- Edit the rules file and add in the patches manually
They really needs to adopt a single patching format, rather than quilt, dpatch, dbs, cdbs, and a bunch of other minor ones.
The sad part about this, is nearly all of these issues also exist in upstream Debian. I'd love to see these get fixed. I'd like more choices that I can run in the enterprise.
I guess the handful of bugs that I found in CentOS and filed at http://bugzilla.redhat.com/ that were fixed must have been a dream. Redhat's bugzilla is a friendly place if you don't need handholding, and just need something fixed.
Of course you can always get support by purchasing a single RHEL license for a single RHEL instance that you run, while the rest of the machines run CentOS, which would still be cheaper than a sitewide support contract from Canonical.
You still have many options for support on CentOS, you just have to get a little creative.
Your math has so many flaws, I'm not even sure where to start.
If you're car was using 100-200hp constantly you'd be hard accelerating up to around a constant rate of about 120-160mph all the time.
Did you actually calculate out how much hp a car uses at a constant real-world speed? It's actually much closer to 10-30hp at freeway speeds all depending on air, tire and transmission resistance. There's many formulas around the internet for this. Pick your favorite.
Charging a car overnight connected to a 240 Volt charger is well within feasible.
Actually, there's much much much more than just Mountain View and Kirkland. Take a look at all the locations for the job reqs:
http://www.google.com/jobs/
Aaaaah, it's always fun when someone brings up one of your old companies. What's funny is that almost all of the development team at ChainCast jumped and is now at NetCableTV. And I always complained about their use of ActiveX (which was going to die at the time due to spyware) and their choice of having a management node architecture instead of a straight network client cloud that could scale itself. I kept telling them they should just mod a pre-existing p2p program to create their entire architecture.
It was an interesting idea, but bad execution.
There sure are:h tml
http://www.eeye.com/html/research/upcoming/index.
This list alone shows 4 unpatched "Severity: High (Remote Code Execution)" issues
Focusing on the original problem of "my cell phone gets bad reception in my house on the mountain" why not purchase a phone that is known for really good reception?
I bought a Nokia phone specifically for it's reception abilities, and I've had many people on the same wireless carrier that couldn't use their phone in places that I could.
Pick up a Nokia 6010 (basic phone) or 6230 (if you need all the features) and see if that fixes your problem.
Why fix the problem with a few hundred thousand dollars when a $100 solution would work.