Actually, 802.1X (on wired ethernet) can be attacked - read this. Yes, it is on Microsoft.com, but nothing in the article is specific to Microsoft technologies.
Now, this is definitely a deliberate attack (not an innocuous vendor just plugging in their laptop to check their email) but it is possible.
(You insert a hub between a legit computer and a legit switch port. You connect your attacking computer to the same hub, configure your attacking computer to have the same MAC, wait for the legit computer to authenticate which opens the switch port and off you go, subject to some caveats as mentioned in the article.)
They recommend IPSec as it authenticates each packet. 802.1X on wireless is not subject to the same issues because there is a session that is maintained between the AP and the client.
Except that it's no longer true. Windows itself is limited to 32,000 (or thereabouts) unicode characters, it's just the ANSI (instead of Unicode) Win32 file I/O functions are limited to 255 characters. See this, for the docs. (Okay, it's a little murky quite where the limits are - but certainly the NT Kernel and NTFS don't have this limitation; the Win32 layer may have it still, especially in the older API calls.)
Because you have to use the Unicode API instead of the ANSI API, there is varying support for long paths among windows programs. As an example, the version of Robocopy distributed with the Windows 2000 resource kit is limited to 255 character paths, but the version distributed with the Windows 2003 is limited to 32k paths.
Argh. As I posted elsewhere, the presence of a BIOS does NOT proove they are not software RAID. In fact, the BIOS is integral to how software RAID systems boot! (At boot time, the BIOS hooks Int 13H allowing the card's BIOS - which is a program that runs on the main CPU - to do specific processing for the RAID, such as parity calculations or mirroring or whatever - but invisibly to the main system BIOS, operating system bootloader or old-skool OS's like MS-DOS.) Effectively, it hooks in its own disc controller driver.
(In fact, this same trick of hooking INT 13h is what allows boot roms on network cards to work - and that's 100% software as the disc access requests are being directed to an image in ram!)
A hardware XOR engine doesn't proove it either - it's possible that the hardware XOR engine runs under control of the OS driver (driver says load this block from this disk, driver then says xor that with this) which is somewhere between fully hardware and software. Not saying this is the case, just that it's theoretically possible.
Now, if you give me a RAID card that works under Linux, Windows, NetBSD and whatever else operating system because it emulates a standard SATA or IDE controller at the hardware level (so much so that you use the same driver for the RAID card as you do for an ordinary controller) *then* you definitely do have hardware RAID. So far, I'm yet to see a card that will work with standard drivers though. What also is definitely hardware raid is external boxes that pretend to be a single disk to a SCSI controller despite containing many drives internally.
IANAL, but nope. As far as I'm aware, taking something to the register is an offer to buy from the retailer, no contract has been formed at this point and hence, no debt. It is, technically, an invitation to treat. Since you're only offering to buy from the retailer, the retailer can reject your offer no matter what currency you have.
Legal Tender, which only deals with physical cash anyway, deals with debt situations. (In a retail situation, the two common examples where legal tender makes a difference is paying for gas after pumping and settiling a resturant account after the meal.)
As an aside, it's perfectly legitmate to work in other currencies, both real (e.g., legal tender in other jurisdictions) and made up (e.g., empty beer bottles) so long as both parties agree - there was a case in New Zealand along those lines, where the Reserve Bank said "Reserve Bank Deputy Governor Murray Sherwin said: "These so-called Chatham Island dollars are harmless as a promotional gimmick and as a bit of fun. Also, if people want to use them to undertake transactions, that's fine too, just as one can pay for a service with monopoly play money, sea shells, or bottles of beer, if the seller is happy to receive them."
Well, actually, you can, or at least could. Sort of. There was a weakeness in the encyrption algorithms of the older SIM cards that let you recover exactly that - the Ki value. As I understood the attack, it involved putting the SIM in a smart card reader and subjecting it to about half an hour's worth of continiuous querying.
I think there was some way you could work out the Ki by sending challange after challange and analysing the responses it gave.
I'd recommend reading this and the subsequent updates linked to from there. Yes, it is from 1998, and I'm hoping that modern SIM cards are more difficult (impossible?) to clone.
It's also possible there are countermeasures too these days built into the SIMs - as you point out, they are active devices.
The official rules (from here) document states the distance is 15.5km/9.6mi, consisting of six laps around a specified oval test track. There's an minimum average speed requirement of 24 kmph/15 mph and a maximum average speed of 40.23kmph/25mph, so real world conditions this is not.
Does ESX Server Run on Linux? On Windows? ESX Server runs natively on server hardware, without a host operating system. The ESX Server virtualization layer is a highly compact and efficient operating system kernel entirely developed by VMware for optimum virtual machine performance. This allows ESX Server to fully manage the hardware resources and provide the highest levels of security and performance isolation. ESX Server also incorporates a service console based on a Linux 2.4 kernel that is used to boot the ESX Server virtualization layer. It also runs ESX Server administration applications.
I agree! ORFEE blocks about 75% of incoming SMTP conenctions for me. The tremendous advantage of ORFEE over a lot of other anti-spam filters is that it can (and does by default) block at the SMTP level (ie, generates a 500 series error instead of 200 okay).
This means that should you accidentally block a legitimate email, the original sender will be notified as their system will send a bounce, but you won't waste everyone's time sending out non-delivery-reports to spam with forged senders.
(The usual approach of merely deleteing email means that a false postitive will be silently lost, and if you tag of otherwise classify spam, user will just ignore/delete everything tagged spam meaning a false postive also won't be noticed.)
Oh, the price is $198 USD per server (unlimited mailboxes, discounts for more servers), including a free 1 year upgrade and support (and Vamsoft do monitor and respond to questions in their very active support newsgroup.) Only servers accepting SMTP connections from the Internet need an installation; a pure back-end server doesn't need one.
It's brilliant, simple, does what it does well, plugs into Exchange or Microsoft SMTPSVC, can optionally intergrate ClamAV or SpamAssassian or other third party programs into the mail flow, DNSBLs (which is the product's original focus), greylisting, SURBL support, HELO/EHLO string scanning, IP Blacklist, Automatic-sender-whitelist (allow addresses that your users send to to reply even if they're on a DNSBL), SPF (Classic) scanning (!), Active Directory address verification (reject incoming sessions to non-existing addresses instead of generating a bounce message later), attachment verification (eg: reject all emails with a.exe or.scr attachment!), all with minimal CPU and RAM use.
It does all this, yet the program is a cohesive whole, easy enough to understand, not a bunch of seemingly random things stuck together.
Er, yeah, that's right, if you want to intergrate ClamAV and/or SpamAssassian into Exchange if you're that way inclined, then here you go.:-)
And you can install it on a seperate Windows 2000/2003 box and use Microsoft SMTP service instead of on your Exchange server itself if you want (so long as it can talk to a domain controller it doesn't have to be on an Exchange server to verify that incoming addresses exist!)
The Wikipedia "Mobile Phone and Data Standards" found, for example, here (on the right hand side) provides a nice summary of various mobile phone and data standards.
How about Corporate: Microsoft provide a server program that you can install that downloads the updates and stores them locally.
Your corporate administrator then configures that server and manually approves and rejects updates to be deployed though the Automatic Update clients connected to your server. (Optionally approving a patch for deployment to only certain groups of computers, say the IT Department could be beta testers.)
It's called Windows Software Update Services, and has been out for quite some time. In other words, all you're asking for in the first half already exists.:-)
The second part you're talking about is deployment of patches that aren't released through automatic updates - and yes, I agree, they're often problematic. It sounds like you manually installed a non-security hotfix, which was then clobbered by a later security patch (and the bugfix wasn't included in the security patch).
Microsoft seem to believe that non-security bugfixes don't belong in security patches unless a lot of people are affected, but it means that for people that need those security patches and bugfixes, it becomes quite a mess trying to maintain them (and may require manual management, as you've found the hard way.:-( ) I think they're tryng to be cautious, which I can understand (although they've in theory fixed this for XPSP2 and 2K3, as those patches are supposed to include "general distribution release" and "quick fix engineering" versions, automatically installing the QFE version if there already is a QFE hotfix installed, otherwise installing the GDR version.)
A classic example of all this is that there's a registry key you can set that causes IE patches to install bugfixed versions. (I'm not kidding.)
The detection logic is (almost certainly) simply the logic built into Windows Update and the automatic update feature that works out whether you need this patch or not. This is nothing new. Microsoft just updates the XML file to contain the relevant "if this dll exists with this version number then offer this patch" information.
It's the same logic that works out whether you need an Office patch or if your computer infected with a certain piece of spyware and offers a special "patch" to get rid of it before offering to install XP SP2 or if a particular patch is already installed so you don't need it again.
It's quite well established code that's been used for quite some time.
I think the main difference is the split between the hypervisor and userspace. (A hypervisor is a scheduler that manages multiple operating systems, each of which has their own scheduler. The original operating systems were called "supervisor programs", in case you're curious, so a supervisor-supervisor-program is a hypervisor.:-)
Under VMWare, each VM runs with its own complete kernel copy - each VM is a complete emulation of a computer, to the best of VMWare's ability.
Under OpenVZ, as far as I can tell, the same kernel is shared among the different VMs and they add extra "namespace" features to the kernel that allows the one kernel to segregate the virtual machines. Because it's still the one kernel, there's more efficency because the one kernel manages the virtual-memory to physical memory mapping and all the other hardware abstraction issues. (Instead of the double layer of the VM ("guest") OS to virtual hardware to the host OS to physical hardware.) If I'm right, this means that a kernel has to be well written to avoid VM contamination, a kernel panic will bring the whole system down (not just one VM), and you can't have different kernel versions or images in each VM.
What I want to know is "how is this in comparison to zones on Solaris?" It looks a lot like that.
There IS an article about Justin Berry - it's just that the current article was rewritten from scratch. So, he is considered worthy of an article in that sense.
I believe the topic at hand is the article that existed prior to 8 March 2006.
Well, as I undersand it, UTMS is the whole protocol stack from airwaves to presentation and the higher level intfrastructure and authentication protocols are still more or less the same as used in traditional GSM.
They certainly share more than just "name" -- as they both use the same SIM cards, the same network infrastructure (they both use the same things like "Home Location Register" and phones do transparently go from GSM to UMTS and vice versa in mid-call.)
"UMTS combines the W-CDMA air interface, GSM's Mobile Application Part (MAP) core, and the GSM family of speech codecs." says Wikipedia.
I think it's fair to say it's still GSM, just as Gigabit Ethernet is still Ethernet despite being very different on the wire to 10 megabit ethernet.
It's very common with GSM phones, at least the 900MHz band GSM phones here in New Zealand. (Only recently has our GSM provider used 1800 MHz - and another commenter suggests that it's only 900 MHz that's susecptable)
It's so familar here, there was an advert on radio that played this very familar brrrrrtth brth brttttth followed by the traditional, Nokia, beep-beep beep-beep of an incoming text message. Every time you heard it you went to check your phone. Even if your phone wasn't that sort of Nokia.:)
Telecom NZ's CDMA phones don't exhibit this.
Besides, the old TDMA GSM standard is being phased out, replaced with the GSM UMTS 2.1 GHz standard, so the problem will eventually go away. (The new standard uses WCDMA underneath, replacing the traditional GSM-TDMA.)
Slight correction - GSM doesn't necesarally use TDMA-the-technique. Traditional GSM does, yes. But the newer 3G standard is a GSM phone but GSM over UMTS. Which, in turn, uses WCDMA (a CDMA variant) over the air.
Tus, the current design is GSM-the-protocol over CDMA-the-technique. (Any such phone is likely to be advertised as 3G and does things like real-time video calling.)
(The 3G phones can fall back to GSM over traditional GSM TDMA however.)
What I look for in a screenshot is the conecptual model of the program and what metaphors it uses. Lets say I see a tree of objects taking up the left hand side. That means that that hierarchy is quite important and is probably the "framework" that the program runs around.
If I see a "toolbox" (e.g., photoshop, Visual Basic) then I know it uses that metaphor. If I see a million and one different confusing buttons arranged all over the show, I know this is going to be a confusing program to understand.
If I see a picture of a real-world CD player, I'll know the design team is more interested in looking cool (for a very deranged value of cool, in this case) rather than writing a computer program.
It's a blog on typepad.com. TypePad is SixApart's hosted MoveableType-esque service and has withstood slashdot in the past, so it's unlikely to melt under the load.:)
The way I see it, the problem here isn't the idea of pay-for 'posting a bond', but the fact there are now multiple providers that aren't equilivant. ("Bonded Sender" and "Goodmail".) Perhaps all the large email companies may start doing this, demanding their own fee, seeing it more as a revenue stream than a spam-control approach.
There are multiple SSL cert providers, but you only have to sign up with one of them. But the way email's looking at the moment, you'll have to sign up with all! What an administrative nightmare! And then imagine the cost of it!
If there was a consortium of "good email vouching organisations" that were respected by the big players, that would be much better.
Re:Yeah, but this is a good thing.
on
Region-free PS3
·
· Score: 1
What I meant is the physical presence of brick and mortar stores means for most game purchases, the region locking doesn't matter as there still is a geographic segementation (allowing differential pricing). (eg: Sony can still charge more in NZ even without region locking for the majority of purchases)
But for someone in this part of the world (I'm in NZ), getting rid of it means that, yes, we can import games from amazon.com or wherever and Sony will thus make sales that they otherwise would not have. Which is also good for their bottom line!
Re:Yeah, but this is a good thing.
on
Region-free PS3
·
· Score: 1
Perhaps - but I suspect a lot of games are bought from local brick and mortar stores, which would allow a certain level of geographic segmentation. After all, people browse the shelves and see what there is to buy and catch up on.
If I want a game, it's faster to go to the store and buy it. If I order it online, I can order it from a local reseller instead of a multinational - better service, faster turnaround.
You're basically praising memcached; which isn't MySQL specific at all. Read Danga's documentation.
Memcached is effectively its own simple associative-array style database, stored purely in memory. It is expected you use another database for the real, persistent storage and then cache the results of database queries using memcached.
Well, see, who cares if they do double swipe it? The *worst* they can do is duplicate the magnetic strip, and that was never secure anyway. (Heck, Borders in Auckland were doing this as a matter of course; they were attacked by one consumer right's group who were worried about the *privacy* issues, not the potential for fraud!)
In New Zealand, we have had a system called EFTPOS since 1983 or so (that's the mid eighties, not a typo). Here, we use standard ATM cards, no chip or anything, that the retailer swipes through a terminal (or increasingly, the customer does) and we type the PIN into a keypad. This tamper-resistant keypad then encrypts the PIN number in conjunction with the transaction details (card number, amount, account selection etc) to the EFTPOS network, and in turn, this is verified with your bank's computer. Only you and your Bank know your PIN. (Note that the terminal that reads your card data isn't trusted by the keypad!) This all happens in real time - no communcation with your bank means you get a clear message on the keypad's display stating the transaction did NOT go through. (You get a clear "ACCEPTED" when it does, and you always get a reciept.)
But, in this whole design, it is assumed that an attacker can clone your card. Without the PIN, this is worthless. Admittidly, it isn't good that they can do this and it is a security improvement that the keypad and "swipers" are, increasingly, in the same unit and done by the customer.
The only way for an attacker to get your pin is (aside from watching you type it) is by compromising the keypad. These things are tamper resisitant - open them up and the crypto keys get erased.
And, no, your PIN isn't stored on your card. It can't be - because when I set the PIN in person at the bank, my new card was NOT swiped through anything after I had entered the number! Also, our ATM/EFTPOS cards have always required PINs - there has never been the option to sign for them (aside from a very cubersome manual process where other ID has to be sighted and all sorts - used only when the EFTPOS network is down or there's a power-cut).
We have had very few cases of fraud in this whole set-up. So much so that when I did loose my ATM card, I rang the bank and they said "it's not really a big concern with a lost ATM card but we'll cancel it anyway." The main attack vector? .
(Note that Credit Cards - because they only require a signature - are more risky - most of the fraud issues in that document are credit cards, not debit/ATM cards. While I have a PIN on my credit card and do use it, I do have the option to sign for it.)
I don't think the PIN should EVER be stored on the card -- because there may be a weakeness in the smart card -- so I believe a more complex protocol where the PIN is verified by the Bank's computer is better.
And, yes, chip is more secure again than our current system -- we are slowly moving down that path, but with 2.5 EFTPOS terminals per hundred New Zealanders, it could take a while. No bank is, as yet, issuing chip cards.
But what about non-CLS* compliant code running in the CLR?
As far as I know, it's possible to have C++ compiled with VS.Net into MSIL and is thus interpreted/jit'd but is still unmanaged because it is using C++ style classes, memory managment and all that.
In fact, I once took the nethack source code, compiled it for Windows using VS.Net 2003 targeting the CLR "processor" instead of x86. It was unmanaged - classic C and C++ memory managment and calls to native library - but was still MSIL, at least as far as I could tell.
*CLS == Commmon Language Specification. MS speak for java-style GC'able type-safe blah blah languages.
"Cycling colors or animated textures can also invigorate a lifeless HUD while decreasing the threat of burn-in."
Aaargh! I HATE gratitious animation in programs. Things should NOT attract my attention unless they are important!
The other problem is that fundementally computer games are running on a computer. They are not real life - thus, a HUD showing "your" health is just part of the connection between you and the game-world. In real life, you would already know how you were feeling.
Slashdot Mirror
Actually, 802.1X (on wired ethernet) can be attacked - read this. Yes, it is on Microsoft.com, but nothing in the article is specific to Microsoft technologies.
Now, this is definitely a deliberate attack (not an innocuous vendor just plugging in their laptop to check their email) but it is possible.
(You insert a hub between a legit computer and a legit switch port. You connect your attacking computer to the same hub, configure your attacking computer to have the same MAC, wait for the legit computer to authenticate which opens the switch port and off you go, subject to some caveats as mentioned in the article.)
They recommend IPSec as it authenticates each packet. 802.1X on wireless is not subject to the same issues because there is a session that is maintained between the AP and the client.
Except that it's no longer true. Windows itself is limited to 32,000 (or thereabouts) unicode characters, it's just the ANSI (instead of Unicode) Win32 file I/O functions are limited to 255 characters. See this, for the docs. (Okay, it's a little murky quite where the limits are - but certainly the NT Kernel and NTFS don't have this limitation; the Win32 layer may have it still, especially in the older API calls.)
Because you have to use the Unicode API instead of the ANSI API, there is varying support for long paths among windows programs. As an example, the version of Robocopy distributed with the Windows 2000 resource kit is limited to 255 character paths, but the version distributed with the Windows 2003 is limited to 32k paths.
Argh. As I posted elsewhere, the presence of a BIOS does NOT proove they are not software RAID. In fact, the BIOS is integral to how software RAID systems boot! (At boot time, the BIOS hooks Int 13H allowing the card's BIOS - which is a program that runs on the main CPU - to do specific processing for the RAID, such as parity calculations or mirroring or whatever - but invisibly to the main system BIOS, operating system bootloader or old-skool OS's like MS-DOS.) Effectively, it hooks in its own disc controller driver.
8 1&cid=15674142
http://hardware.slashdot.org/comments.pl?sid=1904
(In fact, this same trick of hooking INT 13h is what allows boot roms on network cards to work - and that's 100% software as the disc access requests are being directed to an image in ram!)
A hardware XOR engine doesn't proove it either - it's possible that the hardware XOR engine runs under control of the OS driver (driver says load this block from this disk, driver then says xor that with this) which is somewhere between fully hardware and software. Not saying this is the case, just that it's theoretically possible.
Now, if you give me a RAID card that works under Linux, Windows, NetBSD and whatever else operating system because it emulates a standard SATA or IDE controller at the hardware level (so much so that you use the same driver for the RAID card as you do for an ordinary controller) *then* you definitely do have hardware RAID. So far, I'm yet to see a card that will work with standard drivers though. What also is definitely hardware raid is external boxes that pretend to be a single disk to a SCSI controller despite containing many drives internally.
IANAL, but nope. As far as I'm aware, taking something to the register is an offer to buy from the retailer, no contract has been formed at this point and hence, no debt. It is, technically, an invitation to treat. Since you're only offering to buy from the retailer, the retailer can reject your offer no matter what currency you have.
Legal Tender, which only deals with physical cash anyway, deals with debt situations. (In a retail situation, the two common examples where legal tender makes a difference is paying for gas after pumping and settiling a resturant account after the meal.)
As an aside, it's perfectly legitmate to work in other currencies, both real (e.g., legal tender in other jurisdictions) and made up (e.g., empty beer bottles) so long as both parties agree - there was a case in New Zealand along those lines, where the Reserve Bank said "Reserve Bank Deputy Governor Murray Sherwin said: "These so-called Chatham Island dollars are harmless as a promotional gimmick and as a bit of fun. Also, if people want to use them to undertake transactions, that's fine too, just as one can pay for a service with monopoly play money, sea shells, or bottles of beer, if the seller is happy to receive them."
Well, actually, you can, or at least could. Sort of. There was a weakeness in the encyrption algorithms of the older SIM cards that let you recover exactly that - the Ki value. As I understood the attack, it involved putting the SIM in a smart card reader and subjecting it to about half an hour's worth of continiuous querying.
I think there was some way you could work out the Ki by sending challange after challange and analysing the responses it gave.
I'd recommend reading this and the subsequent updates linked to from there. Yes, it is from 1998, and I'm hoping that modern SIM cards are more difficult (impossible?) to clone.
It's also possible there are countermeasures too these days built into the SIMs - as you point out, they are active devices.
The official rules (from here) document states the distance is 15.5km/9.6mi, consisting of six laps around a specified oval test track. There's an minimum average speed requirement of 24 kmph/15 mph and a maximum average speed of 40.23kmph/25mph, so real world conditions this is not.
Does ESX Server Run on Linux? On Windows?
ESX Server runs natively on server hardware, without a host operating system. The ESX Server virtualization layer is a highly compact and efficient operating system kernel entirely developed by VMware for optimum virtual machine performance. This allows ESX Server to fully manage the hardware resources and provide the highest levels of security and performance isolation. ESX Server also incorporates a service console based on a Linux 2.4 kernel that is used to boot the ESX Server virtualization layer. It also runs ESX Server administration applications.
-- http://www.vmware.com/products/esx/faqs.html
So, yeah, Linux might be used as the bootloader and/or system console image.
I agree! ORFEE blocks about 75% of incoming SMTP conenctions for me. The tremendous advantage of ORFEE over a lot of other anti-spam filters is that it can (and does by default) block at the SMTP level (ie, generates a 500 series error instead of 200 okay).
.exe or .scr attachment!), all with minimal CPU and RAM use.
:-)
This means that should you accidentally block a legitimate email, the original sender will be notified as their system will send a bounce, but you won't waste everyone's time sending out non-delivery-reports to spam with forged senders.
(The usual approach of merely deleteing email means that a false postitive will be silently lost, and if you tag of otherwise classify spam, user will just ignore/delete everything tagged spam meaning a false postive also won't be noticed.)
Oh, the price is $198 USD per server (unlimited mailboxes, discounts for more servers), including a free 1 year upgrade and support (and Vamsoft do monitor and respond to questions in their very active support newsgroup.) Only servers accepting SMTP connections from the Internet need an installation; a pure back-end server doesn't need one.
It's brilliant, simple, does what it does well, plugs into Exchange or Microsoft SMTPSVC, can optionally intergrate ClamAV or SpamAssassian or other third party programs into the mail flow, DNSBLs (which is the product's original focus), greylisting, SURBL support, HELO/EHLO string scanning, IP Blacklist, Automatic-sender-whitelist (allow addresses that your users send to to reply even if they're on a DNSBL), SPF (Classic) scanning (!), Active Directory address verification (reject incoming sessions to non-existing addresses instead of generating a bounce message later), attachment verification (eg: reject all emails with a
It does all this, yet the program is a cohesive whole, easy enough to understand, not a bunch of seemingly random things stuck together.
Er, yeah, that's right, if you want to intergrate ClamAV and/or SpamAssassian into Exchange if you're that way inclined, then here you go.
And you can install it on a seperate Windows 2000/2003 box and use Microsoft SMTP service instead of on your Exchange server itself if you want (so long as it can talk to a domain controller it doesn't have to be on an Exchange server to verify that incoming addresses exist!)
The Wikipedia "Mobile Phone and Data Standards" found, for example, here (on the right hand side) provides a nice summary of various mobile phone and data standards.
How about Corporate: Microsoft provide a server program that you can install that downloads the updates and stores them locally.
:-)
:-( ) I think they're tryng to be cautious, which I can understand (although they've in theory fixed this for XPSP2 and 2K3, as those patches are supposed to include "general distribution release" and "quick fix engineering" versions, automatically installing the QFE version if there already is a QFE hotfix installed, otherwise installing the GDR version.)
Your corporate administrator then configures that server and manually approves and rejects updates to be deployed though the Automatic Update clients connected to your server. (Optionally approving a patch for deployment to only certain groups of computers, say the IT Department could be beta testers.)
It's called Windows Software Update Services, and has been out for quite some time. In other words, all you're asking for in the first half already exists.
The second part you're talking about is deployment of patches that aren't released through automatic updates - and yes, I agree, they're often problematic. It sounds like you manually installed a non-security hotfix, which was then clobbered by a later security patch (and the bugfix wasn't included in the security patch).
Microsoft seem to believe that non-security bugfixes don't belong in security patches unless a lot of people are affected, but it means that for people that need those security patches and bugfixes, it becomes quite a mess trying to maintain them (and may require manual management, as you've found the hard way.
A classic example of all this is that there's a registry key you can set that causes IE patches to install bugfixed versions. (I'm not kidding.)
The detection logic is (almost certainly) simply the logic built into Windows Update and the automatic update feature that works out whether you need this patch or not. This is nothing new. Microsoft just updates the XML file to contain the relevant "if this dll exists with this version number then offer this patch" information.
It's the same logic that works out whether you need an Office patch or if your computer infected with a certain piece of spyware and offers a special "patch" to get rid of it before offering to install XP SP2 or if a particular patch is already installed so you don't need it again.
It's quite well established code that's been used for quite some time.
I think the main difference is the split between the hypervisor and userspace. (A hypervisor is a scheduler that manages multiple operating systems, each of which has their own scheduler. The original operating systems were called "supervisor programs", in case you're curious, so a supervisor-supervisor-program is a hypervisor. :-)
Under VMWare, each VM runs with its own complete kernel copy - each VM is a complete emulation of a computer, to the best of VMWare's ability.
Under OpenVZ, as far as I can tell, the same kernel is shared among the different VMs and they add extra "namespace" features to the kernel that allows the one kernel to segregate the virtual machines. Because it's still the one kernel, there's more efficency because the one kernel manages the virtual-memory to physical memory mapping and all the other hardware abstraction issues. (Instead of the double layer of the VM ("guest") OS to virtual hardware to the host OS to physical hardware.) If I'm right, this means that a kernel has to be well written to avoid VM contamination, a kernel panic will bring the whole system down (not just one VM), and you can't have different kernel versions or images in each VM.
What I want to know is "how is this in comparison to zones on Solaris?" It looks a lot like that.
There IS an article about Justin Berry - it's just that the current article was rewritten from scratch. So, he is considered worthy of an article in that sense.
I believe the topic at hand is the article that existed prior to 8 March 2006.
Well, as I undersand it, UTMS is the whole protocol stack from airwaves to presentation and the higher level intfrastructure and authentication protocols are still more or less the same as used in traditional GSM.
They certainly share more than just "name" -- as they both use the same SIM cards, the same network infrastructure (they both use the same
things like "Home Location Register" and phones do transparently go from GSM to UMTS and vice versa in mid-call.)
"UMTS combines the W-CDMA air interface, GSM's Mobile Application Part (MAP) core, and the GSM family of speech codecs." says Wikipedia.
I think it's fair to say it's still GSM, just as Gigabit Ethernet is still Ethernet despite being very different on the wire to 10 megabit ethernet.
It's very common with GSM phones, at least the 900MHz band GSM phones here in New Zealand. (Only recently has our GSM provider used 1800 MHz - and another commenter suggests that it's only 900 MHz that's susecptable)
:)
It's so familar here, there was an advert on radio that played this very familar brrrrrtth brth brttttth followed by the traditional, Nokia, beep-beep beep-beep of an incoming text message. Every time you heard it you went to check your phone. Even if your phone wasn't that sort of Nokia.
Telecom NZ's CDMA phones don't exhibit this.
Besides, the old TDMA GSM standard is being phased out, replaced with the GSM UMTS 2.1 GHz standard, so the problem will eventually go away. (The new standard uses WCDMA underneath, replacing the traditional GSM-TDMA.)
Slight correction - GSM doesn't necesarally use TDMA-the-technique. Traditional GSM does, yes. But the newer 3G standard is a GSM phone but GSM over UMTS. Which, in turn, uses WCDMA (a CDMA variant) over the air.
Tus, the current design is GSM-the-protocol over CDMA-the-technique. (Any such phone is likely to be advertised as 3G and does things like real-time video calling.)
(The 3G phones can fall back to GSM over traditional GSM TDMA however.)
What I look for in a screenshot is the conecptual model of the program and what metaphors it uses. Lets say I see a tree of objects taking up the left hand side. That means that that hierarchy is quite important and is probably the "framework" that the program runs around.
If I see a "toolbox" (e.g., photoshop, Visual Basic) then I know it uses that metaphor. If I see a million and one different confusing buttons arranged all over the show, I know this is going to be a confusing program to understand.
If I see a picture of a real-world CD player, I'll know the design team is more interested in looking cool (for a very deranged value of cool, in this case) rather than writing a computer program.
It's a blog on typepad.com. TypePad is SixApart's hosted MoveableType-esque service and has withstood slashdot in the past, so it's unlikely to melt under the load. :)
The way I see it, the problem here isn't the idea of pay-for 'posting a bond', but the fact there are now multiple providers that aren't equilivant. ("Bonded Sender" and "Goodmail".) Perhaps all the large email companies may start doing this, demanding their own fee, seeing it more as a revenue stream than a spam-control approach.
There are multiple SSL cert providers, but you only have to sign up with one of them. But the way email's looking at the moment, you'll have to sign up with all! What an administrative nightmare! And then imagine the cost of it!
If there was a consortium of "good email vouching organisations" that were respected by the big players, that would be much better.
What I meant is the physical presence of brick and mortar stores means for most game purchases, the region locking doesn't matter as there still is a geographic segementation (allowing differential pricing). (eg: Sony can still charge more in NZ even without region locking for the majority of purchases)
But for someone in this part of the world (I'm in NZ), getting rid of it means that, yes, we can import games from amazon.com or wherever and Sony will thus make sales that they otherwise would not have. Which is also good for their bottom line!
Perhaps - but I suspect a lot of games are bought from local brick and mortar stores, which would allow a certain level of geographic segmentation. After all, people browse the shelves and see what there is to buy and catch up on.
If I want a game, it's faster to go to the store and buy it. If I order it online, I can order it from a local reseller instead of a multinational - better service, faster turnaround.
You're basically praising memcached; which isn't MySQL specific at all. Read Danga's documentation.
Memcached is effectively its own simple associative-array style database, stored purely in memory. It is expected you use another database for the real, persistent storage and then cache the results of database queries using memcached.
Well, see, who cares if they do double swipe it? The *worst* they can do is duplicate the magnetic strip, and that was never secure anyway. (Heck, Borders in Auckland were doing this as a matter of course; they were attacked by one consumer right's group who were worried about the *privacy* issues, not the potential for fraud!)
In New Zealand, we have had a system called EFTPOS since 1983 or so (that's the mid eighties, not a typo). Here, we use standard ATM cards, no chip or anything, that the retailer swipes through a terminal (or increasingly, the customer does) and we type the PIN into a keypad. This tamper-resistant keypad then encrypts the PIN number in conjunction with the transaction details (card number, amount, account selection etc) to the EFTPOS network, and in turn, this is verified with your bank's computer. Only you and your Bank know your PIN. (Note that the terminal that reads your card data isn't trusted by the keypad!) This all happens in real time - no communcation with your bank means you get a clear message on the keypad's display stating the transaction did NOT go through. (You get a clear "ACCEPTED" when it does, and you always get a reciept.)
But, in this whole design, it is assumed that an attacker can clone your card. Without the PIN, this is worthless. Admittidly, it isn't good that they can do this and it is a security improvement that the keypad and "swipers" are, increasingly, in the same unit and done by the customer.
The only way for an attacker to get your pin is (aside from watching you type it) is by compromising the keypad. These things are tamper resisitant - open them up and the crypto keys get erased.
And, no, your PIN isn't stored on your card. It can't be - because when I set the PIN in person at the bank, my new card was NOT swiped through anything after I had entered the number! Also, our ATM/EFTPOS cards have always required PINs - there has never been the option to sign for them (aside from a very cubersome manual process where other ID has to be sighted and all sorts - used only when the EFTPOS network is down or there's a power-cut).
We have had very few cases of fraud in this whole set-up. So much so that when I did loose my ATM card, I rang the bank and they said "it's not really a big concern with a lost ATM card but we'll cancel it anyway." The main attack vector? .
(Note that Credit Cards - because they only require a signature - are more risky - most of the fraud issues in that document are credit cards, not debit/ATM cards. While I have a PIN on my credit card and do use it, I do have the option to sign for it.)
I don't think the PIN should EVER be stored on the card -- because there may be a weakeness in the smart card -- so I believe a more complex protocol where the PIN is verified by the Bank's computer is better.
And, yes, chip is more secure again than our current system -- we are slowly moving down that path, but with 2.5 EFTPOS terminals per hundred New Zealanders, it could take a while. No bank is, as yet, issuing chip cards.
But what about non-CLS* compliant code running in the CLR?
As far as I know, it's possible to have C++ compiled with VS.Net into MSIL and is thus interpreted/jit'd but is still unmanaged because it is using C++ style classes, memory managment and all that.
In fact, I once took the nethack source code, compiled it for Windows using VS.Net 2003 targeting the CLR "processor" instead of x86. It was unmanaged - classic C and C++ memory managment and calls to native library - but was still MSIL, at least as far as I could tell.
*CLS == Commmon Language Specification. MS speak for java-style GC'able type-safe blah blah languages.
"Cycling colors or animated textures can also invigorate a lifeless HUD while decreasing the threat of burn-in."
Aaargh! I HATE gratitious animation in programs. Things should NOT attract my attention unless they are important!
The other problem is that fundementally computer games are running on a computer. They are not real life - thus, a HUD showing "your" health is just part of the connection between you and the game-world. In real life, you would already know how you were feeling.