Well the assumption here is "without IP addresses."
An IP v6 device could be given a unique IP address under Nintendo's IP v6 block, with trillions of spare IP addresses, just assigning static IP addresses.
An IP v4 device could simply make an ICMP broadcast, exactly as DHCP does.
There isn't a need for a proprietary protocol here, although apparently that's what Nintendo has elected to do.
Novell, right now, is not an unknown in the open source world. They've contributed to Linux since before buying SuSE, and they've contributed heavily to project Mono, and are the sole reason why it is more or less the king of the open source implementations of the ECMA.NET framework, and the only implementation with meaningful support for the new beta features in Microsoft's newest framework.
AOL is moving the vast majority of their services onto the web, and supporting their client for dial-up users only in the very near future (cnet reported on this several days ago).
Remote applications are vital. Right now, you have VNC and X which attempt to route the desktop to you, and then you fall all the way to web applications which can't behave very much like the programs users typically use on their desktop.
The next killer application will be developing a standard system to have a program with all the functionality of a fat client on the user's system, while operating on data and processes on a remote server.
We started with monolithic applications, then we implemented terminals on them. Then we implemented client server. Then we took out the client and went back to terminals.
If you look at HTML, it's not a very rich or satisfying task to do things with it. It takes a lot of effort to make something that approximates OO.o's word processor or spreadsheet, for example.
But we know with publisher/subscribe and with web services, that we can send just data over the wire.
We know if there were a generic client that could deal with this just data, that it would be an order of magnitude faster then sending individual drawing commands over the network, and that it would require les bandwidth.
Yes you can do it with Java, or.NET, or the technology de jour, but for it to work and be successful, it needs to be a standardized client that doesn't have to be downloaded every time talking a standardized and extendible protocol.
IBM saw a shift coming 10 years ago. Microsoft saw it as well. IBM acted on it, Microsoft attempted to delay it for as long as possible, but also knew it was coming and inevitable. Had they successfully usurped Java, we would never have seen Windows 98 or Me.
Users, especially in databases, spreadsheets and multimedia (esp. games) are demanding ever increasing levels of performance from computers. The PC as it currently stands cannot deliver what users want.
IBM knew this was coming and made it quite clear that programmers should follow certain techniques. For example, on OS/2, programmers were pushed towards Java. IBM released dozens of examples on using CORBA to interface Java programs to the work place shell. IBM kept pushing Java as the answer, because if you supported Java you could run on Microsoft's OS and theirs, and their Java performance was much higher than either the Sun or Microsoft VM at the time (in some cases four times the Windows version).
IBM has had all of its PC manufacturing outsourced for years. If the shift is towards cell and Power as they predict it will be (I think it's likely that they are correct in this, given how many companies are starting to jump on the bandwagon for power), then their PC division becomes useless deadweight.
If the shift stays on Intel/AMD, then 20% of a healthy PC manufacturer is better than 100% and outsourcing everythnig, and they get a huge cut of China as well.
Curing aids is a much more complex problem than settling another world.
Throughout our evolutionairy history, at every branch, we've made terrible risks to explore. People braved uncurable diseases and trips that killed thousands of people, in order to explore new areas.
Every great revolution in power and transportation, every great revolution in technology coincided with new transportation requirements to get to new areas that humans were exploring.
Everything from the wheel to the space shuttle that we take for granted today were developed as a result of trying to get between places faster.
The larger the distance we've had to cross, the faster the technology has come.
This is a lot of Microsoft's problem. For example, they used libJPEG's code in their JPEG display code. libJPEG had a vulnerability, but many programs used the common code.
And so the problem looked absolutely horrible.
On Open Source, it can be worse. If you look in lib, you'll often see several different versions of the same library (libwhatever-0.0.0, libwhatever-1.0.0), etc. and it is difficult to tell what programs might be linked to what version with what vulnerabilities.
I'm not disagreeing with the setiment, but you have to have good package management and be very careful with what you build by source, or else you can run into problems there too.
Also important here (more important) is good application design.
A hacker cannot get your database information, attach to the database, run arbitrary queries, etc. if your application is properly designed.
You have a front end in a language or environment that provides application level security (Java or Mono -- Python programs running under IronPython or Jython, don't think perl has app level security in any environment, but might be mistaken).
Application level security ensures that if the front end is compromised, its access is limited to only those files, folders or facilities that it has been explicitly granted access to.
Then you connect to a separate server (you can use VM software to run these on a single hardware box, if you need to, or something like User Mode Linux) that has a program that talks to the database.
If you really want to cut off access, you use ssh and require the machine with the database to ssh and then redirect a port back to itself. This is more secure because that machine then accepts no inbound connections (so the web server doesn't need permission to connect out to anything).
You access the database only with stored procedures (yes, this rules out most object relation map software), since the API usually takes an array or collection of parameters, and the API applies escapes, etc. as required automatically.
Stored procedures also have the important trait that they can apply many more and much tighter access requirements than what you usually can apply on a table or view. You can filter records from a result set, etc.
Yeah, it's a lot more work, but a hacker who finds an exploit has a much harder time working deeper, and alot of security is making a system look secure enough that the hacker decides to go after easier prey.
Or use a page with a meta redirect.
1. Send user to www.bankofamerica.com@some-other.com
2. Use a meta-redirect to send user to www.bankofamerica.com
Now spoof stick, etc. are of no help, you're on the legitimate website, and their website has done anything that they want to.
I require JavaScript for my site, on the logon page.
SSL from a web browser cannot be trusted if an internet accelerator or other proxy server, such as Squid, is running. No other authentication method is either supported by every browser or does not pose a serious security risk.
So my option is to use JavaScript and SHA1 and OTP to secure the password, and run on every JavaScript enabled browser, or to use some other mechanism and risk exposure of personal data about my users to unauthorized third parties.
This is not a tax on domain owners, it's an increase in an existing fee charged to the top six domain name roots.
What does this mean to users?
Under its existing agreement with ICANN, VeriSign is permitted to charge resellers $6 for each.com or.net name, a condition that effectively imposes a price floor for each domain. GoDaddy charges $8.95 for a.com or.net domain, for example, while Yahoo Domains will sell the first domain a customer purchases for $4.98 and the remainder for $9.95. Other suffixes with lower price floors are cheaper: The market price for a.biz domain is around $5.
When the bidding to run.net is complete a few months from now, the winning bidder is expected to come up with an annual per-domain charge that's under $6. Even with the additional 75-cent fee
It means prices are coming down. This "tax" is on the registrar. Verisign gets $6 per domain right now for every domain in the.NET area that is sold. Currently, $0.25 of that goes to ICANN. With this change, $1.00 of that goes to ICANN.
This change impacts only whoever runs the root server. Who runs the root server? Verisign does, so since this directly impacts their profit (by lowering it on a per-domain basis), what do they have to say about it?
VeriSign, which currently has the contract to run the master.com and.net databases, broadly endorses the 75-cent fee. Tom Galvin, a VeriSign vice president, said his company is "supportive of the idea of a development fund" of the sort that ICANN wants to create through domain name levies.
First of all, nobody reading this article pays the tax. The tax is paid by Verisign as part of their contract to provide the master databases for ICANN. Again this has absolutely no impact on anyone other than VeriSign, and they agreed to it when they renewed their contract with ICANN.
How is Verisign responding to this massive increase? By lowering the price that they charge to other registrars, such as Go Daddy, EasyDNS, etc., for the root level domains.
Now I left my tin foil hat at home, so you'll have to explain this to me. How, exactly, is ICANN taking Verisign's money bad for anyone reading this article? How exactly is Verisign lowering what they are charging other registrars per domain going to have anything other than a positive impact on the prices of the domains?
Look at the scathing comments about the change from the companies that actually will pay the increased fee:
VeriSign, which currently has the contract to run the master.com and.net databases, broadly endorses the 75-cent fee. Tom Galvin, a VeriSign vice president, said his company is "supportive of the idea of a development fund" of the sort that ICANN wants to create through domain name levies.
Ouch! It sounds like Verisign really believes this increase will hurt its ability to make loads of money off of every domain sold. Listen to that scathing criticism of the plan, even as they are lowering what they are charging other domain name registrars per domain. I really feel bad for them, it sounds like they really don't want for this to happen.
Certainly we can find another biting criticism of the plan from the registrars themselves in the article:
Tim Ruiz, vice president for domain services at GoDaddy, said: "We don't really have a position" on the 75-cent annual fee for.net. GoDaddy says its customers have registered more than 5.3 million domains.
Oh my god how overwhelmingly against Verisign being able to retain a lower cut per-domain. Can't you just feel the a
And everyone said that Hitler wasn't a threat, that we didn't need a defense against him, where did that get the world?
It's funny you should mention Israel, because they are the threat here.
Israel is fighting what they perceive to be a holy war. The other groups in the region are, similarly, fighting a holy war against them. Religion does make people do stupid things.
All it takes is either side deciding they can end the other side fast, and because it is religious, anyone who dies in the process either goes to hell or heaven, depending on which side you are on. That makes it all very convenient.
The real threat is that Israel will do something stupid and someone in the middle east will feel compelled to respond. It could be Egypt, it could be Libya, it could be Iran -- plenty of options there for either side to be stupid, and since the whole region is caught up in a crusade, it's hard to predict what either side might be compelled to do.
This is the scenario I would see...
Israel does something insanely stupid, like launching a chemical, nuclear or biological attack against the Palesteins.
As soon as that happens, all bets are off for direct attack against the US.
Mechs have no practical value, and so you will never see anything resembling the monsters in Battletech/Mechwarrior.
Something the size of a mech has enough mass that inertia makes it impractical to make any reasonable, sudden movement. Even if you assume electronic jamming, a simple dumb fire missle with no electronics could hit with enough force to knock the thing out.
So no, don't expect to ever see anything like mechwarrior.
In order to attack over a long range, you need a reliable mechanism to guide your missle, etc.
Long range transmissions are only viable on Amateur and Military frequencies, and on either of those as soon as someone notices an unauthorized transmitter, it's shut down.
In particular, Amateur's must identify themselves periodically, and are not allowed to send encrypted or encoded transmissions.
You can say "well they could use TCP" and that would be true, but the signal would be there and would have to look like inoccuous traffic. They would have to yield the channel and identify as required by law, and when that didn't happen, their transmitter would be located and shut down within a matter of minutes.
Amateurs train to locate even low power, very intermittent signals. It's called a fox hunt. Often these are even mobile, these days, because people have gotten so good at locating them quickly.
Meanwhile for the military, they need have only two known points and a line of communication to know where they are, and they will have that.
So far as emergency crews go, in a disaster of the scope that they are talking about, you won't need GPS to find casualties, and there is little or no chance of the cell phone network being useable, much less useful, to anyone.
People on/. seem pretty ignorant of that fact. In an emergency involving more than a few people, the cell phone network (and indeed, often the land line network) become unusable fairly quickly.
If there were a missle on its way to London, being guided by GPS, launched from Iran, would you want us to stop it?
Would you call and ask us "can you please stop it?" Do you think that the US general on duty, answering an emergency call from the EU needing part of the GPS shut down to save millions of lives would say "hang on, we need to discuss it in the UN, we'll have an answer for you in a week or two."
I'm sorry, but this can't be a community process. If GPS is being used to coordinate a terrorist attack against a civilian target, it is necessary to be able to turn off that portion of the network, and it's important for it to be able to be done now.
Airplanes and boats navigated before there was GPS. People driving navigated before there was GPS. There are markers on the side of the highway every few meters and every 10th of a mile. In a city, there is a street corner nearby, there's a street your on, there are addresses.
The world survived before GPS, and it would survive even if GPS failed.
However, if GPS -- a convenience -- were being used to launch an active attack on the US or its allies, it wuold be necessary to be able to quickly shut down a portion of the network.
This decision couldn't be a comittee decision, because every hour, minute, second that you wait puts millions of people at risk. You have to make the decision now.
Being able to shut down part of the network is desirable. As long as you can see three satallites, you can know where you are. As soon as you lose any one of the three, you can't triangulate anymore.
If you can shut down just one or two satalites, you can cut visibility to a very specific area.
I'm not saying GPS isn't convenient, I'm not saying its not nice that it's available, but if there are millions of lives at stake, I don't want for us to have to negotiate a shutdown of part of the network with France.
It cannot be a community process in an emergency. If it needs shut down to save lives, then it needs shut down now.
windows 95, 98 and Me are operating environments (similar to KDE or a Java virtual machine) that run on top of DOS.
To use the term "designed" in conjunction with an operating environment that took the already unstable Windows 3.11 "kernel" (it is wrong to call it a kernel) and attempted to make it run pre-emptively multitasked Windows NT code (which uses a true kernel) just was asking for crashes.
3.1x and the first couple versions of 95 literally couldn't run over a month because of a timer overflow. NT based kernels (NT, 2000, XP) tend to be fairly reliable.
My XP boxes reboot only for virus scanner updates and XP service packs. My Linux and Solaris boxes reboot for this reason as well, as does my FreeBSD box.
Failing to reboot means I can't be sure what version of the package existing processes are running. While I could manually determine dependencies and manually restart each individual thing that needs manually restarted, it wouldn't be a terribly efficient process.
My own server processes typically don't need to be rebooted to be upgraded, but I can't force everyone else to design their apps for online upgrades.
Thank you for posting to "$project$-dev." While we appreciate that clueless trolls like yourself have nothing better to do than to agrivate our $project$'s users in the "$project$-dev" list, we would appreciate it if you would please buy a clue.
We feel sorry for the poor users of $project$ because they cannot afford to type the entire word "for," nor can they afford lower case letters to use in their subject line, and as package maintainers, we would very much like to help this segment of our community.
We note that while you say that because $project$ uses $license$, which is an OSI approved open source license, that you feel users should "fix it themselves," however we're compelled to note that we have yet to receive even one fix from any person posting to this list, while it's clear there are a good number of people with legitimate complaints.
And so we, the core developers of "$project$" ask that you please quit suggesting that users should not complain about $license$ software until you are willing to make a useful contribution yourself.
In the mean time, please feel free to use Paypal to donate to the user who cannot afford a complete set of keys.
Dave Bacher $project-position$ $project$ $version$
I'm sure the external hard drive (which used the firewire port on the front of the PS2) is still supported. It just wasn't well known as an option in the US
1) This is another case that points out the need for application-level security.
The issue here is that only the index program should have access to the index. It should not run as another user or system account, because it should have access only to the currently logged in user's files. It shouldn't have to change identities back and forth in order to save the index. This is the root problem.
2) This is as big a problem for Linux as for Windows.
FireFox had a PNG vulnerability that allowed arbitrary code to access. The arguement is "I'm not logged in as root, so it can't do anything," but it can modify your login profile to load spyware. It could load a terminal that ran the terminal you normally use, and grab every key you type. It could do this without root access.
It could insert programs into your X startup scripts, it could hide itself fairly effectively from casual scanning.
It might not be able to get in as deep as with a root or administrator account, but it could get in far enough to do some damage before you were likely to notice it.
The issue here is a key logger or real malicious software doesn't care what it's running as. A DDOS doesn't care if its running as root or not. A spam zombie doesn't care if its running as root or not.
Do you inspect every line of code of every package you install? I didn't think so.
3) What this changes is pretty simple.
Keep in mind Windows can have multiple file systems. For a user, it's likely the only file system is mounted on C:. In a corprate environment, the home directory is usually mounted on another drive, and various corprate resources are mounted on other drives.
A virus has to be able to deal with this, however most viruses are written by college students who have never seen a corprate network. Most of them can't deal with gaps in drive letters. Most of them can't deal with network shares.
The index not only stores an index, and points towards files, but also maintains copies of old versions of the documents. In fact, this is why I like google's indexer so much, there are times I can't remember what change I made to somefile.c, and I don't necessarily check in to CVS/SVN/SourceSafe after every compile.
Anyway, the deal here is now a less sophisticated virus can open one file and find the index, so the virus no longer needs to be able to handle skipped drive letters, etc. It doesn't have to deal with the fact that I might have certain directories that are locked down to a specific user.
But again, application level security is the key here. The reason it's a problem is because any application can access any file that the currently active user can access. Put in application level security, and problem dies.
X.Org, Mesa and your choice of KDE/GNome and the tools necessary to have the same base application set as Windows has have over 5m lines of code, so it's safe to say Apache 2, Samba, etc. weren't included in this count, either, nor the GNU C compiler suite.
There's no central Linux repository for reporting bugs in ancillary packages, while at Microsoft's site, all reported bugs go into a single database that can be queried. Each individual Linux distro and each individual Linux package maintains its own bug lists, which would have to be some how amalgamated.
In order to do the stated comparison, you would need to state what distribution you were using, you would have to state which patches you were using, and you would have to document where the information on bug counts came from for both products.
On top of all this, bugs per 1000 lines of code, while an industry metric, isn't a valid measurement of code quality, either, by the way.
One good code metric is the number of control points per function. The more control points per function, the more likely that you have a bug. It's always possible to take a complicated function and break it up into smaller pieces, and with C/C++ (but not.NET or Java), it's possible to do so with no performance impact at all in all ISO compilers.
Another good metric is the distribution of severity of the reported issues. Draw a bell curve of severity of issues, compare percentage to percentage. You're not concerned with 1000 bugs vs. 100 bugs, you're concerned about how many of those bugs compromise your system or cause a crash.
Another good metric is delta bugs over time. There will always be bugs, everyone knows that there will be bugs. The question is the bug count going up or down.
Another good metric is delta time between open and close. Again, there will always be bugs, but how fast they are getting closed is a measure of whether a product is good or bad.
Another good metric is distribution of the number of days that bugs have been open and reported (by severity).
The reason for this is that the number of lines to implement a given function using a given algorithm varies between programmers and programming styles. Some will use two lines or statements to do what can be done in one, to make code easier to read. The line number is something that a developer can manipulate easily.
However, these other measurements are tied directly into the quality of the code. Nobody cares how big the Linux kernel is compared to the Windows kernel, or vice versa. What they care about is how well the Linux kernel works compared to the Windows kernel.
Any count related to bugs, also, needs to take into account the fact that on Windows, you have billions of users any of whom could find and report a bug. On Linux, bugs are more likely to go undiscovered for a longer period of time, simply because there aren't as many people trying to hit them.
The Windows and Linux kernel tend to be very similar in bug counts. The kernels of both OSes tend not to have bugs, because kernels tend to have simple code that's hard to mess up in any meaningful way.
It's only when you start including all these ancillary subsystems, device drivers, etc. that you start to see significant percentages of the bug.
And it is exceptionally hard to get an accurate count of those on Linux. On vMac, I documented approximately one bug in ten that I fixed, and I think that would be typical of other open source projects (although I can't swear to that).
I think that on these other, valid measurements that aren't dependent on lines of code, that if you could collect the statistics on a package per package basis, and compare them, that Open Source would still come out ahead of Windows.
It's just a matter of using a meaningless metric on widely divergent code bases to prove any point is irresponsible, and by reporting it, the media is doing a disservice to the Open Source community by perpetuating the image of the community as a bunch of college students who don't understand real development practices.
It's targetted at a different market than BitTorrent.
Imagine for example that you are a company distributing a maintenence release of a 40m application.
You seed this on a web server on your US east server, and you have the "swarm" running on US west, EU, Asia Pacific, etc.
Users connect to the proxy, but the proxy can use bandwidth from all of those sites. Assuming most users upgrade during the day, you're probably paying for a lot of bandwidth you're not using, that you could use to distribute the content.
That, I believe, is the target market from reading this. Think about Microsoft, with hundreds of network centers, most of which are empty at any given time. They would need a lot less combined bandwidth if they could distribute a service pack this way.
The issue with Torrent is that Torrent requires client software. This system runs in a proxy on the web server itself, so there is no client side isntallation required.
However, Intel's approach (as stated in several of the articles linked here) can't be produced on standard assembly lines, and requires what IBM described as a "technologically unfeasible" process to produce chips, while apparently the new approach runs on standard manufacturing equipment.
5 hours of playing MP3's, though. If you look at the diary, a lot of their time appears to be related to playing MP3's.
On my TapWave, I can listen to MP3's for a long time without running down the battery, because playing a MP3 requires virtually no processor time. I would guess that if you played a lot of MP3's and played fewer games, you could stretch the batter life a lot.
Slashdot Mirror
Well the assumption here is "without IP addresses."
An IP v6 device could be given a unique IP address under Nintendo's IP v6 block, with trillions of spare IP addresses, just assigning static IP addresses.
An IP v4 device could simply make an ICMP broadcast, exactly as DHCP does.
There isn't a need for a proprietary protocol here, although apparently that's what Nintendo has elected to do.
Novell, right now, is not an unknown in the open source world. They've contributed to Linux since before buying SuSE, and they've contributed heavily to project Mono, and are the sole reason why it is more or less the king of the open source implementations of the ECMA .NET framework, and the only implementation with meaningful support for the new beta features in Microsoft's newest framework.
AOL is moving the vast majority of their services onto the web, and supporting their client for dial-up users only in the very near future (cnet reported on this several days ago).
.NET, or the technology de jour, but for it to work and be successful, it needs to be a standardized client that doesn't have to be downloaded every time talking a standardized and extendible protocol.
Remote applications are vital. Right now, you have VNC and X which attempt to route the desktop to you, and then you fall all the way to web applications which can't behave very much like the programs users typically use on their desktop.
The next killer application will be developing a standard system to have a program with all the functionality of a fat client on the user's system, while operating on data and processes on a remote server.
We started with monolithic applications, then we implemented terminals on them. Then we implemented client server. Then we took out the client and went back to terminals.
If you look at HTML, it's not a very rich or satisfying task to do things with it. It takes a lot of effort to make something that approximates OO.o's word processor or spreadsheet, for example.
But we know with publisher/subscribe and with web services, that we can send just data over the wire.
We know if there were a generic client that could deal with this just data, that it would be an order of magnitude faster then sending individual drawing commands over the network, and that it would require les bandwidth.
Yes you can do it with Java, or
IBM saw a shift coming 10 years ago. Microsoft saw it as well. IBM acted on it, Microsoft attempted to delay it for as long as possible, but also knew it was coming and inevitable. Had they successfully usurped Java, we would never have seen Windows 98 or Me.
Users, especially in databases, spreadsheets and multimedia (esp. games) are demanding ever increasing levels of performance from computers. The PC as it currently stands cannot deliver what users want.
IBM knew this was coming and made it quite clear that programmers should follow certain techniques. For example, on OS/2, programmers were pushed towards Java. IBM released dozens of examples on using CORBA to interface Java programs to the work place shell. IBM kept pushing Java as the answer, because if you supported Java you could run on Microsoft's OS and theirs, and their Java performance was much higher than either the Sun or Microsoft VM at the time (in some cases four times the Windows version).
IBM has had all of its PC manufacturing outsourced for years. If the shift is towards cell and Power as they predict it will be (I think it's likely that they are correct in this, given how many companies are starting to jump on the bandwagon for power), then their PC division becomes useless deadweight.
If the shift stays on Intel/AMD, then 20% of a healthy PC manufacturer is better than 100% and outsourcing everythnig, and they get a huge cut of China as well.
In either event, IBM wins.
Curing aids is a much more complex problem than settling another world.
Throughout our evolutionairy history, at every branch, we've made terrible risks to explore. People braved uncurable diseases and trips that killed thousands of people, in order to explore new areas.
Every great revolution in power and transportation, every great revolution in technology coincided with new transportation requirements to get to new areas that humans were exploring.
Everything from the wheel to the space shuttle that we take for granted today were developed as a result of trying to get between places faster.
The larger the distance we've had to cross, the faster the technology has come.
Just so you realize,
This is a lot of Microsoft's problem. For example, they used libJPEG's code in their JPEG display code. libJPEG had a vulnerability, but many programs used the common code.
And so the problem looked absolutely horrible.
On Open Source, it can be worse. If you look in lib, you'll often see several different versions of the same library (libwhatever-0.0.0, libwhatever-1.0.0), etc. and it is difficult to tell what programs might be linked to what version with what vulnerabilities.
I'm not disagreeing with the setiment, but you have to have good package management and be very careful with what you build by source, or else you can run into problems there too.
Or Mono.
Also important here (more important) is good application design.
A hacker cannot get your database information, attach to the database, run arbitrary queries, etc. if your application is properly designed.
You have a front end in a language or environment that provides application level security (Java or Mono -- Python programs running under IronPython or Jython, don't think perl has app level security in any environment, but might be mistaken).
Application level security ensures that if the front end is compromised, its access is limited to only those files, folders or facilities that it has been explicitly granted access to.
Then you connect to a separate server (you can use VM software to run these on a single hardware box, if you need to, or something like User Mode Linux) that has a program that talks to the database.
If you really want to cut off access, you use ssh and require the machine with the database to ssh and then redirect a port back to itself. This is more secure because that machine then accepts no inbound connections (so the web server doesn't need permission to connect out to anything).
You access the database only with stored procedures (yes, this rules out most object relation map software), since the API usually takes an array or collection of parameters, and the API applies escapes, etc. as required automatically.
Stored procedures also have the important trait that they can apply many more and much tighter access requirements than what you usually can apply on a table or view. You can filter records from a result set, etc.
Yeah, it's a lot more work, but a hacker who finds an exploit has a much harder time working deeper, and alot of security is making a system look secure enough that the hacker decides to go after easier prey.
You don't have to have a prototype for a patent in any current patent system in use in the world, a simple idea is enough.
Or use a page with a meta redirect. 1. Send user to www.bankofamerica.com@some-other.com 2. Use a meta-redirect to send user to www.bankofamerica.com Now spoof stick, etc. are of no help, you're on the legitimate website, and their website has done anything that they want to.
I require JavaScript for my site, on the logon page.
SSL from a web browser cannot be trusted if an internet accelerator or other proxy server, such as Squid, is running. No other authentication method is either supported by every browser or does not pose a serious security risk.
So my option is to use JavaScript and SHA1 and OTP to secure the password, and run on every JavaScript enabled browser, or to use some other mechanism and risk exposure of personal data about my users to unauthorized third parties.
Just put two CSS links on a page that uses a sufficiently complex set of CSS rules, and IE 6 will divide by zero and die.
(two links to the same file)
Works under IE 6 with XP SP2. On IE5.5, it just hides everything, and 5.0 handles it correctly.
FireFox does NTLM just fine. Just have to type "domain\user" and password, and you'll authenticate fine.
What does this mean to users?
It means prices are coming down. This "tax" is on the registrar. Verisign gets $6 per domain right now for every domain in the .NET area that is sold. Currently, $0.25 of that goes to ICANN. With this change, $1.00 of that goes to ICANN.
This change impacts only whoever runs the root server. Who runs the root server? Verisign does, so since this directly impacts their profit (by lowering it on a per-domain basis), what do they have to say about it?
First of all, nobody reading this article pays the tax. The tax is paid by Verisign as part of their contract to provide the master databases for ICANN. Again this has absolutely no impact on anyone other than VeriSign, and they agreed to it when they renewed their contract with ICANN.
How is Verisign responding to this massive increase? By lowering the price that they charge to other registrars, such as Go Daddy, EasyDNS, etc., for the root level domains.
Now I left my tin foil hat at home, so you'll have to explain this to me. How, exactly, is ICANN taking Verisign's money bad for anyone reading this article? How exactly is Verisign lowering what they are charging other registrars per domain going to have anything other than a positive impact on the prices of the domains?
Look at the scathing comments about the change from the companies that actually will pay the increased fee:
Ouch! It sounds like Verisign really believes this increase will hurt its ability to make loads of money off of every domain sold. Listen to that scathing criticism of the plan, even as they are lowering what they are charging other domain name registrars per domain. I really feel bad for them, it sounds like they really don't want for this to happen.
Certainly we can find another biting criticism of the plan from the registrars themselves in the article:
Oh my god how overwhelmingly against Verisign being able to retain a lower cut per-domain. Can't you just feel the a
And everyone said that Hitler wasn't a threat, that we didn't need a defense against him, where did that get the world?
It's funny you should mention Israel, because they are the threat here.
Israel is fighting what they perceive to be a holy war. The other groups in the region are, similarly, fighting a holy war against them. Religion does make people do stupid things.
All it takes is either side deciding they can end the other side fast, and because it is religious, anyone who dies in the process either goes to hell or heaven, depending on which side you are on. That makes it all very convenient.
The real threat is that Israel will do something stupid and someone in the middle east will feel compelled to respond. It could be Egypt, it could be Libya, it could be Iran -- plenty of options there for either side to be stupid, and since the whole region is caught up in a crusade, it's hard to predict what either side might be compelled to do.
This is the scenario I would see...
Israel does something insanely stupid, like launching a chemical, nuclear or biological attack against the Palesteins.
As soon as that happens, all bets are off for direct attack against the US.
No.
Mechs have no practical value, and so you will never see anything resembling the monsters in Battletech/Mechwarrior.
Something the size of a mech has enough mass that inertia makes it impractical to make any reasonable, sudden movement. Even if you assume electronic jamming, a simple dumb fire missle with no electronics could hit with enough force to knock the thing out.
So no, don't expect to ever see anything like mechwarrior.
Even concepts like Patlabor are questionable.
In order to attack over a long range, you need a reliable mechanism to guide your missle, etc.
/. seem pretty ignorant of that fact. In an emergency involving more than a few people, the cell phone network (and indeed, often the land line network) become unusable fairly quickly.
Long range transmissions are only viable on Amateur and Military frequencies, and on either of those as soon as someone notices an unauthorized transmitter, it's shut down.
In particular, Amateur's must identify themselves periodically, and are not allowed to send encrypted or encoded transmissions.
You can say "well they could use TCP" and that would be true, but the signal would be there and would have to look like inoccuous traffic. They would have to yield the channel and identify as required by law, and when that didn't happen, their transmitter would be located and shut down within a matter of minutes.
Amateurs train to locate even low power, very intermittent signals. It's called a fox hunt. Often these are even mobile, these days, because people have gotten so good at locating them quickly.
Meanwhile for the military, they need have only two known points and a line of communication to know where they are, and they will have that.
So far as emergency crews go, in a disaster of the scope that they are talking about, you won't need GPS to find casualties, and there is little or no chance of the cell phone network being useable, much less useful, to anyone.
People on
So why doesn't the EU launch your own GPS system?
If there were a missle on its way to London, being guided by GPS, launched from Iran, would you want us to stop it?
Would you call and ask us "can you please stop it?" Do you think that the US general on duty, answering an emergency call from the EU needing part of the GPS shut down to save millions of lives would say "hang on, we need to discuss it in the UN, we'll have an answer for you in a week or two."
I'm sorry, but this can't be a community process. If GPS is being used to coordinate a terrorist attack against a civilian target, it is necessary to be able to turn off that portion of the network, and it's important for it to be able to be done now.
Airplanes and boats navigated before there was GPS. People driving navigated before there was GPS. There are markers on the side of the highway every few meters and every 10th of a mile. In a city, there is a street corner nearby, there's a street your on, there are addresses.
The world survived before GPS, and it would survive even if GPS failed.
However, if GPS -- a convenience -- were being used to launch an active attack on the US or its allies, it wuold be necessary to be able to quickly shut down a portion of the network.
This decision couldn't be a comittee decision, because every hour, minute, second that you wait puts millions of people at risk. You have to make the decision now.
Being able to shut down part of the network is desirable. As long as you can see three satallites, you can know where you are. As soon as you lose any one of the three, you can't triangulate anymore.
If you can shut down just one or two satalites, you can cut visibility to a very specific area.
I'm not saying GPS isn't convenient, I'm not saying its not nice that it's available, but if there are millions of lives at stake, I don't want for us to have to negotiate a shutdown of part of the network with France.
It cannot be a community process in an emergency. If it needs shut down to save lives, then it needs shut down now.
windows 95, 98 and Me are operating environments (similar to KDE or a Java virtual machine) that run on top of DOS.
To use the term "designed" in conjunction with an operating environment that took the already unstable Windows 3.11 "kernel" (it is wrong to call it a kernel) and attempted to make it run pre-emptively multitasked Windows NT code (which uses a true kernel) just was asking for crashes.
3.1x and the first couple versions of 95 literally couldn't run over a month because of a timer overflow. NT based kernels (NT, 2000, XP) tend to be fairly reliable.
My XP boxes reboot only for virus scanner updates and XP service packs. My Linux and Solaris boxes reboot for this reason as well, as does my FreeBSD box.
Failing to reboot means I can't be sure what version of the package existing processes are running. While I could manually determine dependencies and manually restart each individual thing that needs manually restarted, it wouldn't be a terribly efficient process.
My own server processes typically don't need to be rebooted to be upgraded, but I can't force everyone else to design their apps for online upgrades.
Sir,
Thank you for posting to "$project$-dev." While we appreciate that clueless trolls like yourself have nothing better to do than to agrivate our $project$'s users in the "$project$-dev" list, we would appreciate it if you would please buy a clue.
We feel sorry for the poor users of $project$ because they cannot afford to type the entire word "for," nor can they afford lower case letters to use in their subject line, and as package maintainers, we would very much like to help this segment of our community.
We note that while you say that because $project$ uses $license$, which is an OSI approved open source license, that you feel users should "fix it themselves," however we're compelled to note that we have yet to receive even one fix from any person posting to this list, while it's clear there are a good number of people with legitimate complaints.
And so we, the core developers of "$project$" ask that you please quit suggesting that users should not complain about $license$ software until you are willing to make a useful contribution yourself.
In the mean time, please feel free to use Paypal to donate to the user who cannot afford a complete set of keys.
Dave Bacher
$project-position$
$project$ $version$
I'm sure the external hard drive (which used the firewire port on the front of the PS2) is still supported. It just wasn't well known as an option in the US
1) This is another case that points out the need for application-level security.
The issue here is that only the index program should have access to the index. It should not run as another user or system account, because it should have access only to the currently logged in user's files. It shouldn't have to change identities back and forth in order to save the index. This is the root problem.
2) This is as big a problem for Linux as for Windows.
FireFox had a PNG vulnerability that allowed arbitrary code to access. The arguement is "I'm not logged in as root, so it can't do anything," but it can modify your login profile to load spyware. It could load a terminal that ran the terminal you normally use, and grab every key you type. It could do this without root access.
It could insert programs into your X startup scripts, it could hide itself fairly effectively from casual scanning.
It might not be able to get in as deep as with a root or administrator account, but it could get in far enough to do some damage before you were likely to notice it.
The issue here is a key logger or real malicious software doesn't care what it's running as. A DDOS doesn't care if its running as root or not. A spam zombie doesn't care if its running as root or not.
Do you inspect every line of code of every package you install? I didn't think so.
3) What this changes is pretty simple.
Keep in mind Windows can have multiple file systems. For a user, it's likely the only file system is mounted on C:. In a corprate environment, the home directory is usually mounted on another drive, and various corprate resources are mounted on other drives.
A virus has to be able to deal with this, however most viruses are written by college students who have never seen a corprate network. Most of them can't deal with gaps in drive letters. Most of them can't deal with network shares.
The index not only stores an index, and points towards files, but also maintains copies of old versions of the documents. In fact, this is why I like google's indexer so much, there are times I can't remember what change I made to somefile.c, and I don't necessarily check in to CVS/SVN/SourceSafe after every compile.
Anyway, the deal here is now a less sophisticated virus can open one file and find the index, so the virus no longer needs to be able to handle skipped drive letters, etc. It doesn't have to deal with the fact that I might have certain directories that are locked down to a specific user.
But again, application level security is the key here. The reason it's a problem is because any application can access any file that the currently active user can access. Put in application level security, and problem dies.
X.Org, Mesa and your choice of KDE/GNome and the tools necessary to have the same base application set as Windows has have over 5m lines of code, so it's safe to say Apache 2, Samba, etc. weren't included in this count, either, nor the GNU C compiler suite.
.NET or Java), it's possible to do so with no performance impact at all in all ISO compilers.
There's no central Linux repository for reporting bugs in ancillary packages, while at Microsoft's site, all reported bugs go into a single database that can be queried. Each individual Linux distro and each individual Linux package maintains its own bug lists, which would have to be some how amalgamated.
In order to do the stated comparison, you would need to state what distribution you were using, you would have to state which patches you were using, and you would have to document where the information on bug counts came from for both products.
On top of all this, bugs per 1000 lines of code, while an industry metric, isn't a valid measurement of code quality, either, by the way.
One good code metric is the number of control points per function. The more control points per function, the more likely that you have a bug. It's always possible to take a complicated function and break it up into smaller pieces, and with C/C++ (but not
Another good metric is the distribution of severity of the reported issues. Draw a bell curve of severity of issues, compare percentage to percentage. You're not concerned with 1000 bugs vs. 100 bugs, you're concerned about how many of those bugs compromise your system or cause a crash.
Another good metric is delta bugs over time. There will always be bugs, everyone knows that there will be bugs. The question is the bug count going up or down.
Another good metric is delta time between open and close. Again, there will always be bugs, but how fast they are getting closed is a measure of whether a product is good or bad.
Another good metric is distribution of the number of days that bugs have been open and reported (by severity).
The reason for this is that the number of lines to implement a given function using a given algorithm varies between programmers and programming styles. Some will use two lines or statements to do what can be done in one, to make code easier to read. The line number is something that a developer can manipulate easily.
However, these other measurements are tied directly into the quality of the code. Nobody cares how big the Linux kernel is compared to the Windows kernel, or vice versa. What they care about is how well the Linux kernel works compared to the Windows kernel.
Any count related to bugs, also, needs to take into account the fact that on Windows, you have billions of users any of whom could find and report a bug. On Linux, bugs are more likely to go undiscovered for a longer period of time, simply because there aren't as many people trying to hit them.
The Windows and Linux kernel tend to be very similar in bug counts. The kernels of both OSes tend not to have bugs, because kernels tend to have simple code that's hard to mess up in any meaningful way.
It's only when you start including all these ancillary subsystems, device drivers, etc. that you start to see significant percentages of the bug.
And it is exceptionally hard to get an accurate count of those on Linux. On vMac, I documented approximately one bug in ten that I fixed, and I think that would be typical of other open source projects (although I can't swear to that).
I think that on these other, valid measurements that aren't dependent on lines of code, that if you could collect the statistics on a package per package basis, and compare them, that Open Source would still come out ahead of Windows.
It's just a matter of using a meaningless metric on widely divergent code bases to prove any point is irresponsible, and by reporting it, the media is doing a disservice to the Open Source community by perpetuating the image of the community as a bunch of college students who don't understand real development practices.
It's targetted at a different market than BitTorrent.
Imagine for example that you are a company distributing a maintenence release of a 40m application.
You seed this on a web server on your US east server, and you have the "swarm" running on US west, EU, Asia Pacific, etc.
Users connect to the proxy, but the proxy can use bandwidth from all of those sites. Assuming most users upgrade during the day, you're probably paying for a lot of bandwidth you're not using, that you could use to distribute the content.
That, I believe, is the target market from reading this. Think about Microsoft, with hundreds of network centers, most of which are empty at any given time. They would need a lot less combined bandwidth if they could distribute a service pack this way.
The issue with Torrent is that Torrent requires client software. This system runs in a proxy on the web server itself, so there is no client side isntallation required.
However, Intel's approach (as stated in several of the articles linked here) can't be produced on standard assembly lines, and requires what IBM described as a "technologically unfeasible" process to produce chips, while apparently the new approach runs on standard manufacturing equipment.
5 hours of playing MP3's, though. If you look at the diary, a lot of their time appears to be related to playing MP3's.
On my TapWave, I can listen to MP3's for a long time without running down the battery, because playing a MP3 requires virtually no processor time. I would guess that if you played a lot of MP3's and played fewer games, you could stretch the batter life a lot.