It's not a matter of the format being different, it's which game they ripped off the valid barcode from and how accurately they reproduced the error pattern that goes with it. The source of the valid barcode was different for each region, so they could easily have got tolerances better on the NTSC versions just by chance.
US and Japanese Wiis still read the US/Japanese Freeloader/Action Replay just fine.
Yes, games are pretty much universally more expensive in Europe and this is an economic motive for stopping EU consumers from importing US games, but if they can prevent cracking region protection, surely you'd expect them to include this in *all* consoles - there's no particular reason for them to want to allow anyone to use imports (otherwise they wouldn't have a region protection system in the first place).
It's more likely that it's a simple incompatibility between Datel's reverse-engineered process for making valid Gamecube discs (which must by necessity produce different data on the disc for different regions, as the disc always has to appear to be from the correct region) and the Wii's implementation of the Gamecube disc verification system. They are unlikely to bother to test if all the many different versions of Datel's reverse engineered discs work;)
I didn't know that, though there are other Homebrew methods beyond Action replay, like using Phantasy Star Online or Max Drive Pro... do those not work on PAL Wiis either?
I don't believe the Max Drive Pro's boot disc works on a PAL Wii either - it's based on the same security data as the Action Replay so it's extremely likely that it is also not recognised (and I've not seen anyone anywhere claim that it *does* work). As the other poster indicates, you can't use PSO either as the Wii doesn't emulate the Cube's modem/network adapter and thus the few online Cube games don't work at all, even for just playing normally.
If someone knows a way, I'd be interested to hear it, as there are a few Cube homebrew apps I'd like to be able to run without having to drag my Cube back out of the parts box.:)
They advertise it as running Gamecube Homebrew, but the Wii has been capable of that since day 1 without a chip.
Only NTSC Wii's can run Gamecube homebrew without a chip - it requires an Action Replay to boot the loader, and the PAL Action Replay is not compatible with the Wii for some reason, it refuses to recognise it as a gamecube disc. You can't use an NTSC Action Replay in a PAL Wii as the region protection is not bypassed until you already booted it.:)
So, there is still some value in this for homebrew if you live in a PAL region.
Legality issues aside, you can play download play from any slot 1 or slot 2 device just fine if the DS being downloaded to has been reflashed with a FlashMe firmware.
Download play works by sending a copy of part of the game data over wifi. This data is signed using RSA, to prevent tampering. However, your slot1/2 card modifies the data in some circumstances as it's being read (or in advance, if it's a device which requires a patching tool), as it can't distinguish between code that's going to be run on the local DS (and must thus be patched to run from a non-original card) and code that's going to be downloaded via wifi. The modified code no longer has a valid signature and the target DS refuses to run it.
Flashing with FlashMe removes the signature check from the wireless download client, which allows it to work.
So am I going to be able to get the sources from somewhere and build Java from scratch?
How is this going to work?
You've been able to do that for years - just not under an Open Source licence. Sun have provided the entire JDK source (including the VM code) under their own Sun Community Source Licence (see http://www.sun.com/software/communitysource/j2se/j ava2/download.xml for the current 1.5 code). There are various restrictions imposed by the SCSL which prevent free redistribution of changes unless you comply with certain conditions, and thus it's not considered to be an OSS licence.
You need a bunch of binaries to get it bootstrapped (i.e. it requires Java to build Java) but the result is entirely compiled from the source you can get from the above site.;)
GPLing it is a change of licence terms, not a change in the actual availability of the source.
On video game consoles with a USB port, is the lack of support for USB HID gamepads in games more likely the fault A. of the game developers or B. of the console makers?
It's the console makers in the case of the Xbox. The original Xbox's kernel ignores any USB device that doesn't match one of the expected vendor/type IDs. All the third party pads copy the IDs of the original MS pad. The 360 when running with cabled controllers does exactly the same. The only way to support devices that MS didn't include support for is to skip the kernel calls that initialise the input system, and then implement the entire USB stack yourself from scratch by poking the host controller's registers directly - something homebrew software has done, but not really a great option for game developers.
The PS2 is a slightly different situation - the USB ports on the PS2 are not used for anything at all normally, and support for hardware attached to them comes included in the relevant games (e.g. EyeToy Play knows how to drive a USB webcam). Any PS2 game could support any USB device, but they'd have to include the whole driver stack. I have no idea what level of support Sony provide for this; I expect they provide the USB stack itself but drivers for the hardware for your game would be your own problem.
Many free apps that stopped working on Series 60 3.0 stopped working because the APIs they use have been changed; Symbian 9.1 (upon which S60 3.0 is based) was used as the opportunity to remove a lot of deprecated functionality, and fix many design problems. Doing all the compatibility breaks at once hopefully saves breaking things a few at a time over all the subsequent releases (the Windows approach, no? *grin*).
There is some reasonable provision for freeware and OSS software under Platform Security, as other posters have pointed out. The problem seems mostly to be a matter of perception at the moment; the information as to what is and is not possible is not perhaps as obvious as it could be, and OSS developers haven't had enough time to deal with the changes yet, since 9.1-derived phones are relatively new to the actual consumer market.
Nokia are increasingly using S60 as a marketing tactic, and this will gain them nothing if 'this phone uses S60' doesn't mean 'this phone can run loads of apps you can find easily online'. This is going to mean supporting free (and Free) software, even if there's been a bit of a bumpy start perhaps:)
Maybe, but who cares that you can't make it run Linux? You can download games and actually play them now. That's good enough for 98% of the people who would be interested in this development.
The one problem that still remains with this is there's no way to run games from a different region or video system; the region checks still apply. So, you can't download a game that's been released in the US and play it on your European 360. The Xbox was never very interesting from an import POV, though (as opposed to other consoles with many.jp-only releases, or EU releases only much later after multi-language translation), so this isn't that major I guess:)
Actually, x86-64 does have some speed benefits over standard ia32 for smaller programs and data sets in that it doubles the number of exposed registers.
But unfortunately to *access* the extra registers, you have to use extra prefixes/suffixes on the instructions (because x86-64's instruction set is a strict superset), which makes them longer, which eats up more Icache. The small benefit of having the extra registers visible to the compiler is often reduced or squashed entirely by a few percent more cache churn =(
The extreme out-of-order execution of modern x86 chips, and the fact that they have *way* more registers than are even exposed by x86-64, already takes care of this problem in quite a lot of cases (just keep values around in extra registers, defer all memory accesses as late as possible, and generally mess with the linear order until it all comes out in the wash *grin*).
Yes, but how many of those 1-record-updates were triggered by a single "transaction". If I write a loop which updates records one-at-a-time then you'll get a million 1-record-updates, but that doesn't mean that it wouldn't benefit from being enclosed in a transaction.
The database is primarily used to serialise and deserialise state, most pagehits generate exactly one UPDATE to one row (the user's account). There are no loops like that. The data happen to be structured such that the atomicity of writing to a single row is sufficient to maintain consistency at all times.
Also - atomicity is about more that DB writes. What happens if you query the same record 5 times in generating a report/webpage/whatever. If you enclose the SELECTs in a transaction they are guaranteed to return the same result. If you don't then they could be inconsistent.
Which is why the application doesn't do that. The state of each thing the app is interested in examining is fetched from the database a maximum of once in a single pagehit, and in almost every case there is no requirement that the states being read be atomic with each other, because they are independant and no cross-table consistency is required.
All a transaction does is make DB IO seem instantaneous, even if it wasn't. With a transaction, you can do a SELECT that returns 25 GB of data over a DSL line, and the last record returned was in the state it was the command was issued.
I know exactly what transactions do, I've written many apps that use them. But, this one doesn't. It has a local database and it rarely needs to select more than one row or update more than one row at a time.
Now, I still think that allowing transactions to be disabled for the sake of performance is fine, as it gives control to the developer. However, I'd only trust a developer to make that determination if they were well versed in DB concepts - far too many folks have a transactions-are-overrated philosophy without understanding why they are often important.
Where did I imply that transactions are overrated? Transactions are a vital part of many database applications and to try and do those applications without them is foolish. The simple fact I was trying to note is that there are still, whether you have ever developed one or not, applications that have absolutely no use for transactions whatsoever, and thus it's no big deal for them to run on a database that doesn't have them.
I made that determination for my application because I am well versed in DB concepts. A major design principle was to never implement anything in the application code that would have been cleaner/safer/faster to do in the database layer, just to overcome a shortcoming of the database. It was not a design principle to ensure it would work on MyISAM tables, or even on MySQL at all - it just happened to turn out that way because I never needed to overstep the bounds of what MyISAM can do, and that's quite handy because it means the app works for people who use MySQL.
incorrect/fud. you modify the version in dllcache, nothing happens; then when you modify the system32 version, it checks the dllcache version, see it's corrupt (signature/checksum failed) and will prompt you for product cd.
I haven't tried doing that, but one thing that *definately* works (because it's how I replace uxtheme.dll) is to just delete the version in dllcache, then modify the one in system32. It will ask for the CD to replace it, you hit cancel, and it forgets all about it. The file will get reverted if updated by a service pack/hotfix, but nothing else will touch it.
It gains you nothing if you make changes to one *row* of one table at a time. This is a fairly rare use case.
Says who? I develop a database-heavy webapp and a quick grep through the query logs show that about 96% of UPDATE queries include a WHERE clause that specifies a primary key value, and thus by definition only change one row.
Applications are all different. I'm sure there are loads of applications where single-row updates are extremely rare, but your application is not my application;)
The app I develop has never needed to use transactions, and I've never felt that the client code would be any simpler if transactions were available: it just is that way, for what I'm doing. So MyISAM is a pretty good choice - it means the app runs nicely fast, even though it does a lot of queries.
It works fine on PostgreSQL too, the DB layer can be switched straight over. I've not benchmarked one against the other, but I would be surprised if the MyISAM performance was worse;)
Choices are a great thing: for every task where MyISAM would be hopelessly inadequate, there's a task where it works just fine.
I was working on porting Windows XP to Xen (without the benefit of VT/Pacifica, which is now the 'right' way to do this - it was some time ago, before those techs were announced). It was kinda fun;)
Got to stick my hands in the Windows source, and futz with it. It got quite far but it was never what you might call 'stable'. It also took about 15-20 minutes to do the first few seconds' worth of booting due to the vast, vast amount of debug information we had it dumping out of the serial port. 295MB bootlogs anyone?
With VT/Pacifica it should be a breeze. I'm not actively involved in developing Xen any more (though I do use several Xen machines), but it's a nifty project and works impressively well (even if people don't actually understand how the hell it works *grin*)
Actually I'm the one being a pedant. It's not a modification of the Linux kernel at all, though older versions did borrow heavily from the Linux device driver code - the Xen hypervisor is a totally seperate chunk of code and would theoretically be capable of running without a Linux in sight at all, as long as some other guest was able to perform the tasks of domain 0.
Xen's host components *do* run directly on the metal, they just don't talk to I/O devices. Xen controls the processor and memory, and provides inter-domain communications. It is an OS in its own right, just a very, very limited one that can do nothing other than schedule and communicate between its guests.
The original version of Xen included the device drivers for the real hardware in the Xen hypervisor, making domain 0 even less special - domain 0 accessed the hardware through the virtual device layer the same as all the others. This was changed to the current model to avoid having to maintain a complete device driver layer in the hypervisor.
Domain 0 is *not special*. It has been given permission to start other domains (but you can give that permission to any domain, not just dom0) and it is by default given permission to talk to all the hardware (but you can give selective rights to access particular bits of hardware to any domain - you could even run a seperate domain for each device driver, so that a bug in the SCSI driver can't affect the network driver, for example).
You totally misunderstand the Xen architecture;)
BTW, I worked for the Xen development team at Cambridge University, working for Ian Pratt, who is now the Xen project leader at XenSource. So I really should be familiar with its design...
You can't run Xen on Linux - Xen is a freestanding hypervisor that runs directly on the metal. So, the statement in the article seems perfectly reasonable. (this is, incidentally, one of the (numerous) advantages of Xen over VMWare in the performance stakes - being able to control the hardware directly instead of having to mess around with what the host OS will let you do is quicker).
Every OS on a Xen system is a guest OS. Some of them just have permission to create new OS instances, or access particular bits of real hardware directly.
System management mode is present on all i686-class chips, including AMD. There are a number of ways to enter it, most of which depend on the motherboard - overheating a P4 is just one way.
If there exists any way to get an AMD processor on a given board to enter SMM for any reason, it's vulnerable to the same trick.
Ah, but actually that still makes the not-compressible files grow a little - you have to include at least one extra bit of information to indicate whether the rest of the file is compressed or not;)
Or if you want to keep using Live as well, just softmod it using a save and dash exploit. Don't even have to open the case, does everything a chip/tsop flash does (other than let you change the boot screen) and you can still play on Live. Total cost is however much Blockbuster charge to rent one of the exploitable games.
I fired up Remote Desktop and connected to his computer to install the drivers, since he didn't have admin rights. When I tried to log in, I was informed that there was another user already connected, and if I proceeded, he would be disconnected.
So if only one user can be logged in at a time, how can that be considered a multi-user system?
Multiple users can be logged in at a time, just not through Remote Desktop. Remote Desktop is just Terminal Services, artificially crippled to stop you from using an XP machine as a terminal server (they want you to pay for a server edition of Windows for that).
You can have multiple users logged in graphically with Fast User Switching, though only one gets to use the console at a time; you can have processes running that belong to any number of users if they don't need a desktop (e.g. Task Scheduler, can run tasks as any user no matter who is logged in); you can run processes as a specific user if you know that user's password and they will be able to interact with your desktop; you can have many users logged in via the telnet server.. and any other app that feels like doing the same stuff (say, OpenSSH for Cygwin) can do it too.
So yes, it is a real multiuser system, though whether it's a good one I shall not comment on;)
Didn't Microsoft just force an Xbox 360 upgrade that made a demo disc unplayable once the full version was for sale?
No, Microsoft just forced an Xbox 360 upgrade that made a kiosk demo disc (i.e. for game stores to use on their demo consoles, not sold to home users) not run on people's 360s any more, because it had incorrectly had the media flags set to allow the (signed and therefore unalterable) executables to be run from non-Xbox media. This meant that you could take a copy of the disk onto DVD-R and it would still run in your 360. Various people are experimenting with modifying the data on the disk (you can change the data files, just not the executables which are signed) to try and discover a software exploit that will enable the running of arbitrary code. MS wanted this to stop, so they blacklisted the disc in a Live update.
Also when the maximum amount of TCP connections is 65536 (16 bit unsigned integer in TCP-frame) simultanously, that is really amazing thing they've done or am I missing some big picture here?
The maximum number of TCP connections is unbounded. The maximum number of locally initiated TCP connections is 65535 (you aren't supposed to use port 0).
You can have as many people connected to a single server listen port as you want, new connections do not use a new port number. Only the 4-tuple of (client IP, client port, server IP, server port) has to be unique.
It's still impressive that they can scale that well, though - this just isn't amazing in itself;)
It's not just implementing new crypto algorithms that causes security failures; implementing new processes, new protocols, new ways of using the same crypto primitives you know and trust do it too.
Using your example, it is indeed entirely possible to use Blowfish to encrypt all the data in a table. But, if you do it in a naieve way, the protection afforded by the (perfectly good choice of) primitive will be reduced or lost entirely.
The GP poster was probably more worried about this kind of error. Read Bruce Schneier's "Secrets and Lies", or Ross Anderson's "Computer Security", for many, many examples of why implementing your own security system involving crypto is *very* hard and *does* require you to be an expert.
If the database had, built in, a crypto system that was designed by an expert and which only required you to flip the right switches and chuck in a few keys to make it work, *that* would be far more likely to be secure than rolling your own methods.
Slashdot Mirror
Oh, that's quite plausible too, but still.
It's not a matter of the format being different, it's which game they ripped off the valid barcode from and how accurately they reproduced the error pattern that goes with it. The source of the valid barcode was different for each region, so they could easily have got tolerances better on the NTSC versions just by chance.
US and Japanese Wiis still read the US/Japanese Freeloader/Action Replay just fine.
;)
Yes, games are pretty much universally more expensive in Europe and this is an economic motive for stopping EU consumers from importing US games, but if they can prevent cracking region protection, surely you'd expect them to include this in *all* consoles - there's no particular reason for them to want to allow anyone to use imports (otherwise they wouldn't have a region protection system in the first place).
It's more likely that it's a simple incompatibility between Datel's reverse-engineered process for making valid Gamecube discs (which must by necessity produce different data on the disc for different regions, as the disc always has to appear to be from the correct region) and the Wii's implementation of the Gamecube disc verification system. They are unlikely to bother to test if all the many different versions of Datel's reverse engineered discs work
If someone knows a way, I'd be interested to hear it, as there are a few Cube homebrew apps I'd like to be able to run without having to drag my Cube back out of the parts box.
So, there is still some value in this for homebrew if you live in a PAL region.
Legality issues aside, you can play download play from any slot 1 or slot 2 device just fine if the DS being downloaded to has been reflashed with a FlashMe firmware.
Download play works by sending a copy of part of the game data over wifi. This data is signed using RSA, to prevent tampering. However, your slot1/2 card modifies the data in some circumstances as it's being read (or in advance, if it's a device which requires a patching tool), as it can't distinguish between code that's going to be run on the local DS (and must thus be patched to run from a non-original card) and code that's going to be downloaded via wifi. The modified code no longer has a valid signature and the target DS refuses to run it.
Flashing with FlashMe removes the signature check from the wireless download client, which allows it to work.
Never tried. The SCSL download page links to a set of binaries which will successfully build the code, and are free-as-in-beer.
You've been able to do that for years - just not under an Open Source licence. Sun have provided the entire JDK source (including the VM code) under their own Sun Community Source Licence (see http://www.sun.com/software/communitysource/j2se/
You need a bunch of binaries to get it bootstrapped (i.e. it requires Java to build Java) but the result is entirely compiled from the source you can get from the above site.
GPLing it is a change of licence terms, not a change in the actual availability of the source.
It's the console makers in the case of the Xbox. The original Xbox's kernel ignores any USB device that doesn't match one of the expected vendor/type IDs. All the third party pads copy the IDs of the original MS pad. The 360 when running with cabled controllers does exactly the same. The only way to support devices that MS didn't include support for is to skip the kernel calls that initialise the input system, and then implement the entire USB stack yourself from scratch by poking the host controller's registers directly - something homebrew software has done, but not really a great option for game developers.
The PS2 is a slightly different situation - the USB ports on the PS2 are not used for anything at all normally, and support for hardware attached to them comes included in the relevant games (e.g. EyeToy Play knows how to drive a USB webcam). Any PS2 game could support any USB device, but they'd have to include the whole driver stack. I have no idea what level of support Sony provide for this; I expect they provide the USB stack itself but drivers for the hardware for your game would be your own problem.
Many free apps that stopped working on Series 60 3.0 stopped working because the APIs they use have been changed; Symbian 9.1 (upon which S60 3.0 is based) was used as the opportunity to remove a lot of deprecated functionality, and fix many design problems. Doing all the compatibility breaks at once hopefully saves breaking things a few at a time over all the subsequent releases (the Windows approach, no? *grin*).
:)
There is some reasonable provision for freeware and OSS software under Platform Security, as other posters have pointed out. The problem seems mostly to be a matter of perception at the moment; the information as to what is and is not possible is not perhaps as obvious as it could be, and OSS developers haven't had enough time to deal with the changes yet, since 9.1-derived phones are relatively new to the actual consumer market.
Nokia are increasingly using S60 as a marketing tactic, and this will gain them nothing if 'this phone uses S60' doesn't mean 'this phone can run loads of apps you can find easily online'. This is going to mean supporting free (and Free) software, even if there's been a bit of a bumpy start perhaps
The one problem that still remains with this is there's no way to run games from a different region or video system; the region checks still apply. So, you can't download a game that's been released in the US and play it on your European 360. The Xbox was never very interesting from an import POV, though (as opposed to other consoles with many
Actually, x86-64 does have some speed benefits over standard ia32 for smaller programs and data sets in that it doubles the number of exposed registers.
But unfortunately to *access* the extra registers, you have to use extra prefixes/suffixes on the instructions (because x86-64's instruction set is a strict superset), which makes them longer, which eats up more Icache. The small benefit of having the extra registers visible to the compiler is often reduced or squashed entirely by a few percent more cache churn =(
The extreme out-of-order execution of modern x86 chips, and the fact that they have *way* more registers than are even exposed by x86-64, already takes care of this problem in quite a lot of cases (just keep values around in extra registers, defer all memory accesses as late as possible, and generally mess with the linear order until it all comes out in the wash *grin*).
Yes, but how many of those 1-record-updates were triggered by a single "transaction". If I write a loop which updates records one-at-a-time then you'll get a million 1-record-updates, but that doesn't mean that it wouldn't benefit from being enclosed in a transaction.
The database is primarily used to serialise and deserialise state, most pagehits generate exactly one UPDATE to one row (the user's account). There are no loops like that. The data happen to be structured such that the atomicity of writing to a single row is sufficient to maintain consistency at all times.
Also - atomicity is about more that DB writes. What happens if you query the same record 5 times in generating a report/webpage/whatever. If you enclose the SELECTs in a transaction they are guaranteed to return the same result. If you don't then they could be inconsistent.
Which is why the application doesn't do that. The state of each thing the app is interested in examining is fetched from the database a maximum of once in a single pagehit, and in almost every case there is no requirement that the states being read be atomic with each other, because they are independant and no cross-table consistency is required.
All a transaction does is make DB IO seem instantaneous, even if it wasn't. With a transaction, you can do a SELECT that returns 25 GB of data over a DSL line, and the last record returned was in the state it was the command was issued.
I know exactly what transactions do, I've written many apps that use them. But, this one doesn't. It has a local database and it rarely needs to select more than one row or update more than one row at a time.
Now, I still think that allowing transactions to be disabled for the sake of performance is fine, as it gives control to the developer. However, I'd only trust a developer to make that determination if they were well versed in DB concepts - far too many folks have a transactions-are-overrated philosophy without understanding why they are often important.
Where did I imply that transactions are overrated? Transactions are a vital part of many database applications and to try and do those applications without them is foolish. The simple fact I was trying to note is that there are still, whether you have ever developed one or not, applications that have absolutely no use for transactions whatsoever, and thus it's no big deal for them to run on a database that doesn't have them.
I made that determination for my application because I am well versed in DB concepts. A major design principle was to never implement anything in the application code that would have been cleaner/safer/faster to do in the database layer, just to overcome a shortcoming of the database. It was not a design principle to ensure it would work on MyISAM tables, or even on MySQL at all - it just happened to turn out that way because I never needed to overstep the bounds of what MyISAM can do, and that's quite handy because it means the app works for people who use MySQL.
incorrect/fud. you modify the version in dllcache, nothing happens; then when you modify the system32 version, it checks the dllcache version, see it's corrupt (signature/checksum failed) and will prompt you for product cd.
I haven't tried doing that, but one thing that *definately* works (because it's how I replace uxtheme.dll) is to just delete the version in dllcache, then modify the one in system32. It will ask for the CD to replace it, you hit cancel, and it forgets all about it. The file will get reverted if updated by a service pack/hotfix, but nothing else will touch it.
It gains you nothing if you make changes to one *row* of one table at a time. This is a fairly rare use case.
;)
;)
Says who? I develop a database-heavy webapp and a quick grep through the query logs show that about 96% of UPDATE queries include a WHERE clause that specifies a primary key value, and thus by definition only change one row.
Applications are all different. I'm sure there are loads of applications where single-row updates are extremely rare, but your application is not my application
The app I develop has never needed to use transactions, and I've never felt that the client code would be any simpler if transactions were available: it just is that way, for what I'm doing. So MyISAM is a pretty good choice - it means the app runs nicely fast, even though it does a lot of queries.
It works fine on PostgreSQL too, the DB layer can be switched straight over. I've not benchmarked one against the other, but I would be surprised if the MyISAM performance was worse
Choices are a great thing: for every task where MyISAM would be hopelessly inadequate, there's a task where it works just fine.
I was working on porting Windows XP to Xen (without the benefit of VT/Pacifica, which is now the 'right' way to do this - it was some time ago, before those techs were announced). It was kinda fun ;)
Got to stick my hands in the Windows source, and futz with it. It got quite far but it was never what you might call 'stable'. It also took about 15-20 minutes to do the first few seconds' worth of booting due to the vast, vast amount of debug information we had it dumping out of the serial port. 295MB bootlogs anyone?
With VT/Pacifica it should be a breeze. I'm not actively involved in developing Xen any more (though I do use several Xen machines), but it's a nifty project and works impressively well (even if people don't actually understand how the hell it works *grin*)
Actually I'm the one being a pedant. It's not a modification of the Linux kernel at all, though older versions did borrow heavily from the Linux device driver code - the Xen hypervisor is a totally seperate chunk of code and would theoretically be capable of running without a Linux in sight at all, as long as some other guest was able to perform the tasks of domain 0.
;)
Xen's host components *do* run directly on the metal, they just don't talk to I/O devices. Xen controls the processor and memory, and provides inter-domain communications. It is an OS in its own right, just a very, very limited one that can do nothing other than schedule and communicate between its guests.
The original version of Xen included the device drivers for the real hardware in the Xen hypervisor, making domain 0 even less special - domain 0 accessed the hardware through the virtual device layer the same as all the others. This was changed to the current model to avoid having to maintain a complete device driver layer in the hypervisor.
Domain 0 is *not special*. It has been given permission to start other domains (but you can give that permission to any domain, not just dom0) and it is by default given permission to talk to all the hardware (but you can give selective rights to access particular bits of hardware to any domain - you could even run a seperate domain for each device driver, so that a bug in the SCSI driver can't affect the network driver, for example).
You totally misunderstand the Xen architecture
BTW, I worked for the Xen development team at Cambridge University, working for Ian Pratt, who is now the Xen project leader at XenSource. So I really should be familiar with its design...
You can't run Xen on Linux - Xen is a freestanding hypervisor that runs directly on the metal. So, the statement in the article seems perfectly reasonable. (this is, incidentally, one of the (numerous) advantages of Xen over VMWare in the performance stakes - being able to control the hardware directly instead of having to mess around with what the host OS will let you do is quicker).
Every OS on a Xen system is a guest OS. Some of them just have permission to create new OS instances, or access particular bits of real hardware directly.
System management mode is present on all i686-class chips, including AMD. There are a number of ways to enter it, most of which depend on the motherboard - overheating a P4 is just one way.
If there exists any way to get an AMD processor on a given board to enter SMM for any reason, it's vulnerable to the same trick.
Ah, but actually that still makes the not-compressible files grow a little - you have to include at least one extra bit of information to indicate whether the rest of the file is compressed or not ;)
Or if you want to keep using Live as well, just softmod it using a save and dash exploit. Don't even have to open the case, does everything a chip/tsop flash does (other than let you change the boot screen) and you can still play on Live. Total cost is however much Blockbuster charge to rent one of the exploitable games.
I fired up Remote Desktop and connected to his computer to install the drivers, since he didn't have admin rights. When I tried to log in, I was informed that there was another user already connected, and if I proceeded, he would be disconnected.
;)
So if only one user can be logged in at a time, how can that be considered a multi-user system?
Multiple users can be logged in at a time, just not through Remote Desktop. Remote Desktop is just Terminal Services, artificially crippled to stop you from using an XP machine as a terminal server (they want you to pay for a server edition of Windows for that).
You can have multiple users logged in graphically with Fast User Switching, though only one gets to use the console at a time; you can have processes running that belong to any number of users if they don't need a desktop (e.g. Task Scheduler, can run tasks as any user no matter who is logged in); you can run processes as a specific user if you know that user's password and they will be able to interact with your desktop; you can have many users logged in via the telnet server.. and any other app that feels like doing the same stuff (say, OpenSSH for Cygwin) can do it too.
So yes, it is a real multiuser system, though whether it's a good one I shall not comment on
Didn't Microsoft just force an Xbox 360 upgrade that made a demo disc unplayable once the full version was for sale?
No, Microsoft just forced an Xbox 360 upgrade that made a kiosk demo disc (i.e. for game stores to use on their demo consoles, not sold to home users) not run on people's 360s any more, because it had incorrectly had the media flags set to allow the (signed and therefore unalterable) executables to be run from non-Xbox media. This meant that you could take a copy of the disk onto DVD-R and it would still run in your 360. Various people are experimenting with modifying the data on the disk (you can change the data files, just not the executables which are signed) to try and discover a software exploit that will enable the running of arbitrary code. MS wanted this to stop, so they blacklisted the disc in a Live update.
Also when the maximum amount of TCP connections is 65536 (16 bit unsigned integer in TCP-frame) simultanously, that is really amazing thing they've done or am I missing some big picture here?
;)
The maximum number of TCP connections is unbounded. The maximum number of locally initiated TCP connections is 65535 (you aren't supposed to use port 0).
You can have as many people connected to a single server listen port as you want, new connections do not use a new port number. Only the 4-tuple of (client IP, client port, server IP, server port) has to be unique.
It's still impressive that they can scale that well, though - this just isn't amazing in itself
It's not just implementing new crypto algorithms that causes security failures; implementing new processes, new protocols, new ways of using the same crypto primitives you know and trust do it too.
Using your example, it is indeed entirely possible to use Blowfish to encrypt all the data in a table. But, if you do it in a naieve way, the protection afforded by the (perfectly good choice of) primitive will be reduced or lost entirely.
The GP poster was probably more worried about this kind of error. Read Bruce Schneier's "Secrets and Lies", or Ross Anderson's "Computer Security", for many, many examples of why implementing your own security system involving crypto is *very* hard and *does* require you to be an expert.
If the database had, built in, a crypto system that was designed by an expert and which only required you to flip the right switches and chuck in a few keys to make it work, *that* would be far more likely to be secure than rolling your own methods.
I guess it makes it so you can't use your spell checker anymore either?
;)
The hotkey for his spell checker is probably shift+something