I am having a great deal of difficulty writing this, because I can't find words that are sufficiently vituperative that aren't obscene or hackneyed.
This makes Apple's "Metal", as dumb an idea as it was, seem like a paragon of consistency by comparison. I mean, look, we have a brushed aluminum theme, we have toolbars replacing menus... and the toolbars themselves being replaced by sticky menus that look like folder tabs, that pull down more toolbars...
And they're actively confusing.
Look at the first picture. "Write" is selected. What does "Write" mean? Well, I'd assume that it had something to do with handwriting or with saving files, but no, "Write" simply seems to be the default tab... but the next tab is marked "Insert". I have no idea what "Insert" means, but it can't be "insert mode". Can it?
Then there's the "Table Tools". It's hilighted in orange. What does that mean? Who cares? If it's not selected it shouldn't be hilighted. If it's selected, then Write shouldn't be hilighted.
I can go on, but there's just too much brokenness in this. it reminds me of the horrible sidebar-and-borders and jello-not-aqua junk on IE on the Mac, except this one goes to 11.
I think you're prediccting the present. Integrating? No. Selling or sopporting/promoting? They already do that with SoftWindows, so I imagine they'll continue to do so with that or some similar product in the future. I doubt it would be included by default... i see no advantage for Apple in that.
"As far as the inherent security of Macs, it cannot defeat user stupidity, so that point is rather moot, IMO. Most of the serious virus epidemics seem to be email or web based these days."
And one of the reasons is that the most common email and web based applications use the Microsoft HTML control, which has an inherently insecure design. The Windows user interface depends in many places on the ability of HTML documents to launch native code with full local user permissions. In the case of the control panel, it's not even acceptable to interrupt the user with the inadequate "security dialogs" that the HTML control brings up for documents it doesn't trust.
I do not believe it is acceptable for the HTML control itself to have this ability at all. A security mechanism should "fail closed", so that the normal situation is that the dangerous actions are impossible and some external mechanism - one that can't be invoked from the HTML control itself - has to intervene to provide these mechanisms.
Safari works that way. Safari itself has no mechanism to run native code, and if you turn off "open safe files after downloading" there's no supported mechanism in Safari to run code provided by another site. Dashboard uses Webkit, like Safari, but it adds extensions to Webkit for native code support.
Internet Explorer on Windows doesn't do that. Instead, it has a "trusted" security zone in which native code support works. There have been repeated cases where an attacker has managed to inject a native executable or script into this zone, by various chichanery in email messages or web pages, and use that to perform the initial intrusion.
This is a HUGE difference.
And it has made a HUGE difference on Windows. Before this was introduced around 1997 viruses on Windows were more common than on other systems... but you could generally get by without antivirus software if you didn't download and run random applications. The whole idea of being able to run code just by viewing a mail message was a joke (literally, there was a joke going around about a "GOOD TIMES" virus, and it was a joke in part because just viewing email was normally safe).
Then came "Active Desktop" and its followons. The virus population on Windows skyrocketed. Not because people were suddenly buying that many more Windows based computers, but because the *system security* of Windows had taken a nosedive.
And until Microsoft changes this, Windows will remain a "Typhoid Mary" of the cybernetic world. And unless Apple changes the way their mail and web software works, it will never approach the infection level that Windows enjoys... EVEN IF it had comparable market share to Windows.
*system security* does matter, and it's NOT a "moot point".
What I want is for the people who make these mice and keyboards and things with extra buttons to publish an API, so you could use the mouse indicators from other applications... say, turn the light on when you get an IM, or "pulse" it if you get an email from someone important.
Or, even, use the extra functions from other operating systems... so you don't need to wait for Logitech to write "Mouseware for Linux".
It's not (just) the difference between the IQs each cartoon markets to, it's simply smoother, better graphics which look as though they took more than five minutes of effort and three years of age to create.
The graphics in Wind Walker are brilliant. They're smooth, fast, and technically demanding. They're not trying to emulate Pixar or the latest SIGGRAPH output, but they used the latest technologies in a whole new way. The sylized smoke and simulated cels are just as hard to do right as the painstakingly rendered dirt and grime in Half Life.
These aren't "low quality" in any sense. They're just a more subtle kind of quality than you're used to. Yes, it's "toony", but it's compellingly toony... it's not "toony because it's all we can do", it's "toony because it's hard to do well".
It starts off with a stock piece of Apple propaganda about their overblown and misunderstood "Fitt's law", and goes on to the thing I hate most about the old Finder... "spatial navigation".
Sorry, Apple, when I have thousands of folders I don't want to have to click through them one by one with each new folder in a different part of the screen... my muscle memory is based on what programs do, not where the files they use live on the disk.
I don't want to remember that the spatula goes in the drawer under the sink. I want to hold my hand out and say "spatula" and have it teleported into my hand by the replicator. I can't do that in "real life", but I can do it in my computer... and now I don't have to teach my muscles what drawer the spatula is in, and I can concentrate on teaching them how to use it.
As for the corners... screen corners are crummy places to put controls.
On Mac OS X there's about seven zillion utilities you can get to let you do things with the screen corners, and I've tried maybe half a zillion of them, and they all suck. Why?
First, dragging the mouse to the screen corner blows the context of what you were working on. It's an easy place to hit, but as soon as you've hit it you need to get back to where you started. The net result is that you're worse off than you would be if you had to click a "hard to hit" pop-up menu.
Second, three of the four screen corners are already occupied by the Apple menu, my calendar (on the menu bar), and my trashcan (because I have it pinned to the corner). I've got the third corner set for "start screen saver" because if I put it anywhere else it goes off by accident too easily.
Ah, you say, I have my trash-can in the corner. Yeh, because that makes it easier to hit for those cases where I *really* need to hit it. For the rest I normally hit the context menu and select "move to trash", or use the "delete" icon in my finder toolbar.
Panning... that's a job for a three-button mouse. Grab with the third button and drag. Logitech's mouse driver in Windows lets you do this, and it's great. I'll take it over scroll wheels any time.
Finally: Tip a quarter to the right, crop by half and e-mail to Stevie Wonder.
Wow, I've been using THAT interface for 30 years!
pnmrotate 90 picture | pnmscale 0.5 | uuencode picture | Mail -s "Here's the picture" stevie@wonder.invalid
But there are no portable machines with the G5 processor.
There are also no portable machines with the e600 processor, the new G4-cored chips coming from Freescale. Why not? Because they're only just getting to the sampling stage.
These chips should be to the G5 what the Pentium M is to the P4: a small short-pipeline core that gets more work done per clock cycle, tied to a high bandwidth bus. Intel finally caught on that it's not so muc about CPU speed any more as it is about I/O bandwidth... and went from a 133 Mhz FSB to a 533 MHz FSB and the resulting chip made the P4 look poorly. Freescale's going from 166 MHz to two 768 MHz memory busses and separate PCI-X ports on-chip... which should give any P-M a run for its money even at 3/4 of the CPU clock speed.
That's why I noted that I didn't know "if it had longer legs than your 9290, but it was at the very least no worse."
You do know there's a variety of phones around today of different wieghts and sizes.
And battery life, just like in 2000. And the longer the battery life, all other things being equal, the bigger the battery (and thus the phone) has to be.
My Nokia got briefly replaced by a Pocket PC phone that supported MP3 playing and bluetooth, and I had a Wifi card for it. I couldn't realy use the MP3 support, because it ran the battery down faster than the phone did on standby... and then when my battery ran down because I was on the phone for too long, I couldn't call out on a wired line to complete the call because the phone number I needed was in the PDA I couldn't use because the battery was flat.
That was enough for me. That much convergence in devices will have to weight for new battery technology.
My new phone is about 1/3 shorter but actually heavier than my old bar, it's harder to use, and if I forget to charge it at least very other day (which means I end up having to charge it every) it's toast. It's got a color screen and ringtone support and some kind of internet software and a game downloader that I couldn't be arsed figuring out how to use.
I carry a PDA, a phone, and usually an iPod shuffle. If I don't carry the shuffle it's not because it's too many things, it's because the earphones are too much of a pain to deal with.
All put together they weigh less than your 9000, and fit in different pockets so no one of them is bulky enough to matter...
I don't have to worry about not being able to place a call or get to my PDA's data because my MP3 player ran them down.
And I don't have to leave my PDA behind when I go somewhere phones aren't allowed.
And if someone ganks my iPod I can afford to just buy a new one.
I don't carry a camera much, though I did for most of last summer for a photo project. It's not something I'm much nterested in... but if I was going to get one I'd buy something like a Zire 72 rather than a camera phone... the PDA has more "slack" in the battery life than the phone does because it's not running a radio transceiver all the time.
Let's split the difference. The phone I had in 2000 could easily go a long weekend of casual use out of range of AC without worrying about it going flat. It had over a week of standby, and a day of heavy use didn't mean obsessing over getting it plugged in by the time I got home.
It also never rebooted at 3AM playing a darling little tune and scaring the hell out of the cat (and hence me).
I don't know if it had longer legs than your 9290, but it was at the very least no worse. And...
my old 9290 had that, and battery life was close to a week.... your phone weighed, what, 3x as much as my little "bar" and was half again as long. And mine phone was at the upper end of the size that was worth carrying.
Why bruce keeps harping on security...
on
Do You Code Sign?
·
· Score: 1
I'll skip point #1, though it's pretty important, because I think you have an idea why it's there.
#2) Just because a component is signed doesn't mean that it is safe.
Code signing was design to prove the authenticity and integrity of the code. It was never designed to certify that the piece is also securely written.
But it doesn't do that unless you have a secure automatic revocation mechanism. And if you have such a mechanism, you don't need Code Signing! because the only way to make sure that a piece of code you're presented with isn't on a revocation list is to check the revocation list when you're presented with it... and if you can do that, why do you need to sign the code? You can directly verify the authenticity and integrity of the code by downloading a checksum instead of a revocation list.
#5) The fact that the evidence of attack (the signature on the code) is stored on the computer under attack is mostly useless: The attack could delete or modify the signature during the attack, or simple reformat the drive where the signature is stored.
My comments: I am not sure what this statement means.
Two things. First, he's pointing out that Code Signing isn't useful for forensics. For example, if someone attacks you using a compromisable signed applet they can remove the evidence that they did it. Secondly and more importantly the signature database becomes a new source of exploits: if you can compromise the signature database, you can sign your exploit code!
Basically, Code Signing is a tool that you can use to reduce the risks incurred by doing something inherently risky: automatically running unrestricted code provided by a potentially untrusted source. There are two reasons you might want to do this: first, because you're concerned with the performance impact of running the untrusted code in a sandbox; second, because you want to avoid the organizational cost of distributing applications to end-users through other mechanisms.
In practice, the performance impact of sandboxing has become a moot point, given the speed of modern computers and the efficiency and capability of scripting languages. The difference between the scripted Google Maps and the native Microsoft Streets and Trips is almost entirely attributable to the difference between remote and local map storage. The user interface itself is similarly smooth and responsive when you're not hitting the network.
As for distribution, the complexity and the amount of manual work involved in making sure each computer is configured to securely allow appropriate signed applets to run without opening up security holes is significant. I find it hard to imagine that distributing software through traditional mechanisms would not be an improvement. Even Microsoft's Software Update requires at least one manual verification step the first time you use it that comparable update mechanisms that use individual package signatures (hashes) manage to avoid.
And it doesn't implement secure automatic revocation, which means that if you find an exploit in a signed package you can continue to use that package as part of an exploit... if the package had to be explicitly downloaded from a secure server, or if a hash of the package had to be fetched from a secure server before it was accepted, then this attack mechanism wouldn't exist.
So... deploying signed code reduces security when compared to explicitly installed code or checksummed packages: it opens you up for attacks from old versions of the package, and it opens you up to attacks that compromise the local signature database.
Which is why Schnier brings up these points... it's not that these are attacks that Code Signing is supposed to prevent, rather they're attacks that Code Signing makes easier.
Running a 64bit processor on a 32bit OS (forcing 32bit software) is as bad as running 32bit software on a 64bit OS
Yes, but that could be anything from "very bad indeed" to "it actually runs faster" depending on the hardware. On the Alpha trapping unaligned accesses will kill you, but on most RISCs you're usually better off in 32-bit mode if you don't need the larger address space.
The performance difference between running Windows 32bit and Windows 64bit with 64bit applications IS significant
You have no way of knowing that unless you've implemented both a 32-bit and 64-bit Windows using the same instruction set architecture, because Microsoft hasn't done that for you. Heck, they don't even give you the option of really using either 32 and 64 bit models using the AMD64 ISA. The only tests that have been done have been between the AMD64 ISA and the IA32 ISA on the AMD64 hardware, and the larger register file on AMD64 completely swamps any effects the word size might have on performance.
And, in fact, Windows in 64-bit mode is far from a pure 64-bit model. Most of the word sizes are the same as in 32-bit mode, and unless an application has been redesigned to use the new 64-bit types it's still effectively a 32-bit application. It has a larger address space, but I for one would be extremely reluctant to use it without auditing the whole program for pointer/index truncation bugs.
A GSM/GPRS/UMTS phone, preferably one that takes two SIMs, allowing it to listen on two networks simultaneously. Quadband and UMA support would beperfect
A 3 megapixel Kodak-quality camera
The ability to act as an 802.11g peer or hub, with the machine showing up as a basic server on the network that you can just copy files to and from, plus network routing for when the phone's in GPRS/etc mode.
A 10G (or better) mini-HD, so I can store all my music rather than have to decide what music I'm going to listen to in advance
Good MP3 and Ogg support
Standardized 2.5mm handsfree and 3.5mm stereo headset jacks
Openable to reveal a landscape touchscreen plus a minikeyboard
Don't forget:
A Pony.
A backpack for the battery.
Personally, I want my old Nokia back, with its monochrome screen and no data service or ringtones and enough battery life that I could use it for a whole long weekend without charging or rationing...
While it would be nice to have tabs and a search box in IE, those are not the features of Firefox that make me use it. If you did something like "block ActiveX in IE", you'd get close, but then all those things that require IE wouldn't work.
Copy the MS HTML control, binary patch the copy so it has its own registry keys and profile and doesn't get confused with the original. That includes its own HKEY_CLASSES_ROOT!
Using these patched keys, configure it so it will ONLY run ActiveX controls from %SYSTEMROOT%\system32\%GENSYM%\chrome - I guess it might be safe to make everything not in that directory "internet zone" and set its version of "internet zone" to disable scripting, the whole kit and caboodle.
Now you can copy the controls you know are safe to use and necessary for to function as a web browser into that directory, and put a bare minimum of applications in its HKEY_CLASSES_ROOT.
Then patch the IE "shell" and Outlook to use this control.
Windows owns around a 95% marketshare and Macintosh has around a 1.9%, and Linux has around a 2%. Please note that I am talking client not server OS.
Where are you getting these numbers?
The Mac market share in the use for 4Q04 was 2.9%, for 1Q05 3.7%. That's higher than IBM/Lenovo.
Linux is harder to measure, but it's not strong on the desktop. Servers, yes, but desktops? A year ago it was pushing close to Apple, 2.8% to 2.9% if I'm reading IDC's summary right, and if Apple loses market share over the Intel switch it may briefly surpass the Mac... but there's no way it's matched the 45% year-over-year growth that Apple's currently enjoying.
A $200 premium on a $500 computer is sort of serious.
You only say that because you're not used to paying a 100% "Mac Tax".
Apple's gross margins are generally reported as being about 40%. They're possibly lower than that on the mini... last time I priced a generally comparable PC it was only $150 less.
Dell's margins may be negative in some cases, if you don't finance.
That's why Apple can support developing their own OS, and I find that a worthwhile tradeoff.
Avalon / Xaml replaces how you create user interfaces.
It might replace how you create user interfaces, but using a metalanguage like XML or the Tk layout engine has been pretty ordinary stuff elsewhere for a long time.
I won't be managing my data in WinFS this decade. Throw my data into another Windows-specific honeytrap? No thanks.
DotNET? Yet another patch on the proven-unfixable "Security Zones" model that Microsoft's been failing to implement securely since 1997? No thanks.
The people who need 64 bit are already using 64-bit. They're doing it because they have to, because they're getting an advantage from the larger words and address spaces to counter the performance hit of throwing up to twice as much data around to do anything.
Alpha and AMD64 are not counterexamples. Alpha got its performance boost from a better overall architecture. AMD64 boxes are not getting a performance win from the 64-bitness of the code, but more from the larger register file. You don't need "pure 64-bit" to get this.
You can use a dynamic (smart and updated continuously) playlist to get that effect, by using "Limit to songs selected by play count".
I find this doesn't work all that well, because there's positive feedback in it. If I selected songs manually more often that would work better, but I don't do that.
I have found that I get interesting results by loading my iPod shuffle with a selection from my weighted playlist selected by LEAST often played.
I am having a great deal of difficulty writing this, because I can't find words that are sufficiently vituperative that aren't obscene or hackneyed.
This makes Apple's "Metal", as dumb an idea as it was, seem like a paragon of consistency by comparison. I mean, look, we have a brushed aluminum theme, we have toolbars replacing menus... and the toolbars themselves being replaced by sticky menus that look like folder tabs, that pull down more toolbars...
And they're actively confusing.
Look at the first picture. "Write" is selected. What does "Write" mean? Well, I'd assume that it had something to do with handwriting or with saving files, but no, "Write" simply seems to be the default tab... but the next tab is marked "Insert". I have no idea what "Insert" means, but it can't be "insert mode". Can it?
Then there's the "Table Tools". It's hilighted in orange. What does that mean? Who cares? If it's not selected it shouldn't be hilighted. If it's selected, then Write shouldn't be hilighted.
I can go on, but there's just too much brokenness in this. it reminds me of the horrible sidebar-and-borders and jello-not-aqua junk on IE on the Mac, except this one goes to 11.
1. OSX intergrating Wine or VMWare.
I think you're prediccting the present. Integrating? No. Selling or sopporting/promoting? They already do that with SoftWindows, so I imagine they'll continue to do so with that or some similar product in the future. I doubt it would be included by default... i see no advantage for Apple in that.
"As far as the inherent security of Macs, it cannot defeat user stupidity, so that point is rather moot, IMO. Most of the serious virus epidemics seem to be email or web based these days."
And one of the reasons is that the most common email and web based applications use the Microsoft HTML control, which has an inherently insecure design. The Windows user interface depends in many places on the ability of HTML documents to launch native code with full local user permissions. In the case of the control panel, it's not even acceptable to interrupt the user with the inadequate "security dialogs" that the HTML control brings up for documents it doesn't trust.
I do not believe it is acceptable for the HTML control itself to have this ability at all. A security mechanism should "fail closed", so that the normal situation is that the dangerous actions are impossible and some external mechanism - one that can't be invoked from the HTML control itself - has to intervene to provide these mechanisms.
Safari works that way. Safari itself has no mechanism to run native code, and if you turn off "open safe files after downloading" there's no supported mechanism in Safari to run code provided by another site. Dashboard uses Webkit, like Safari, but it adds extensions to Webkit for native code support.
Internet Explorer on Windows doesn't do that. Instead, it has a "trusted" security zone in which native code support works. There have been repeated cases where an attacker has managed to inject a native executable or script into this zone, by various chichanery in email messages or web pages, and use that to perform the initial intrusion.
This is a HUGE difference.
And it has made a HUGE difference on Windows. Before this was introduced around 1997 viruses on Windows were more common than on other systems... but you could generally get by without antivirus software if you didn't download and run random applications. The whole idea of being able to run code just by viewing a mail message was a joke (literally, there was a joke going around about a "GOOD TIMES" virus, and it was a joke in part because just viewing email was normally safe).
Then came "Active Desktop" and its followons. The virus population on Windows skyrocketed. Not because people were suddenly buying that many more Windows based computers, but because the *system security* of Windows had taken a nosedive.
And until Microsoft changes this, Windows will remain a "Typhoid Mary" of the cybernetic world. And unless Apple changes the way their mail and web software works, it will never approach the infection level that Windows enjoys... EVEN IF it had comparable market share to Windows.
*system security* does matter, and it's NOT a "moot point".
What I want is for the people who make these mice and keyboards and things with extra buttons to publish an API, so you could use the mouse indicators from other applications... say, turn the light on when you get an IM, or "pulse" it if you get an email from someone important.
Or, even, use the extra functions from other operating systems... so you don't need to wait for Logitech to write "Mouseware for Linux".
It's not (just) the difference between the IQs each cartoon markets to, it's simply smoother, better graphics which look as though they took more than five minutes of effort and three years of age to create.
The graphics in Wind Walker are brilliant. They're smooth, fast, and technically demanding. They're not trying to emulate Pixar or the latest SIGGRAPH output, but they used the latest technologies in a whole new way. The sylized smoke and simulated cels are just as hard to do right as the painstakingly rendered dirt and grime in Half Life.
These aren't "low quality" in any sense. They're just a more subtle kind of quality than you're used to. Yes, it's "toony", but it's compellingly toony... it's not "toony because it's all we can do", it's "toony because it's hard to do well".
It starts off with a stock piece of Apple propaganda about their overblown and misunderstood "Fitt's law", and goes on to the thing I hate most about the old Finder... "spatial navigation".
Sorry, Apple, when I have thousands of folders I don't want to have to click through them one by one with each new folder in a different part of the screen... my muscle memory is based on what programs do, not where the files they use live on the disk.
I don't want to remember that the spatula goes in the drawer under the sink. I want to hold my hand out and say "spatula" and have it teleported into my hand by the replicator. I can't do that in "real life", but I can do it in my computer... and now I don't have to teach my muscles what drawer the spatula is in, and I can concentrate on teaching them how to use it.
As for the corners... screen corners are crummy places to put controls.
On Mac OS X there's about seven zillion utilities you can get to let you do things with the screen corners, and I've tried maybe half a zillion of them, and they all suck. Why?
First, dragging the mouse to the screen corner blows the context of what you were working on. It's an easy place to hit, but as soon as you've hit it you need to get back to where you started. The net result is that you're worse off than you would be if you had to click a "hard to hit" pop-up menu.
Second, three of the four screen corners are already occupied by the Apple menu, my calendar (on the menu bar), and my trashcan (because I have it pinned to the corner). I've got the third corner set for "start screen saver" because if I put it anywhere else it goes off by accident too easily.
Ah, you say, I have my trash-can in the corner. Yeh, because that makes it easier to hit for those cases where I *really* need to hit it. For the rest I normally hit the context menu and select "move to trash", or use the "delete" icon in my finder toolbar.
Panning... that's a job for a three-button mouse. Grab with the third button and drag. Logitech's mouse driver in Windows lets you do this, and it's great. I'll take it over scroll wheels any time.
Finally: Tip a quarter to the right, crop by half and e-mail to Stevie Wonder.
Wow, I've been using THAT interface for 30 years!
pnmrotate 90 picture | pnmscale 0.5 | uuencode picture | Mail -s "Here's the picture" stevie@wonder.invalid
What *do* we see when a star undergoes gravitational collapse and subsequent explosion after having spent all of its nuclear fuel?
Now that they're nuclear-free, they retire to New Zealand and work as extras for Peter Jackson.
But there are no portable machines with the G5 processor.
There are also no portable machines with the e600 processor, the new G4-cored chips coming from Freescale. Why not? Because they're only just getting to the sampling stage.
These chips should be to the G5 what the Pentium M is to the P4: a small short-pipeline core that gets more work done per clock cycle, tied to a high bandwidth bus. Intel finally caught on that it's not so muc about CPU speed any more as it is about I/O bandwidth... and went from a 133 Mhz FSB to a 533 MHz FSB and the resulting chip made the P4 look poorly. Freescale's going from 166 MHz to two 768 MHz memory busses and separate PCI-X ports on-chip... which should give any P-M a run for its money even at 3/4 of the CPU clock speed.
Just like my Nokia 9290, you mean?
That's why I noted that I didn't know "if it had longer legs than your 9290, but it was at the very least no worse."
You do know there's a variety of phones around today of different wieghts and sizes.
And battery life, just like in 2000. And the longer the battery life, all other things being equal, the bigger the battery (and thus the phone) has to be.
My Nokia got briefly replaced by a Pocket PC phone that supported MP3 playing and bluetooth, and I had a Wifi card for it. I couldn't realy use the MP3 support, because it ran the battery down faster than the phone did on standby... and then when my battery ran down because I was on the phone for too long, I couldn't call out on a wired line to complete the call because the phone number I needed was in the PDA I couldn't use because the battery was flat.
That was enough for me. That much convergence in devices will have to weight for new battery technology.
My new phone is about 1/3 shorter but actually heavier than my old bar, it's harder to use, and if I forget to charge it at least very other day (which means I end up having to charge it every) it's toast. It's got a color screen and ringtone support and some kind of internet software and a game downloader that I couldn't be arsed figuring out how to use.
I carry a PDA, a phone, and usually an iPod shuffle. If I don't carry the shuffle it's not because it's too many things, it's because the earphones are too much of a pain to deal with.
All put together they weigh less than your 9000, and fit in different pockets so no one of them is bulky enough to matter...
I don't have to worry about not being able to place a call or get to my PDA's data because my MP3 player ran them down.
And I don't have to leave my PDA behind when I go somewhere phones aren't allowed.
And if someone ganks my iPod I can afford to just buy a new one.
I don't carry a camera much, though I did for most of last summer for a photo project. It's not something I'm much nterested in... but if I was going to get one I'd buy something like a Zire 72 rather than a camera phone... the PDA has more "slack" in the battery life than the phone does because it's not running a radio transceiver all the time.
It's 2005, not 1995.
... your phone weighed, what, 3x as much as my little "bar" and was half again as long. And mine phone was at the upper end of the size that was worth carrying.
Let's split the difference. The phone I had in 2000 could easily go a long weekend of casual use out of range of AC without worrying about it going flat. It had over a week of standby, and a day of heavy use didn't mean obsessing over getting it plugged in by the time I got home.
It also never rebooted at 3AM playing a darling little tune and scaring the hell out of the cat (and hence me).
I don't know if it had longer legs than your 9290, but it was at the very least no worse. And...
my old 9290 had that, and battery life was close to a week.
I'll skip point #1, though it's pretty important, because I think you have an idea why it's there.
#2) Just because a component is signed doesn't mean that it is safe.
Code signing was design to prove the authenticity and integrity of the code. It was never designed to certify that the piece is also securely written.
But it doesn't do that unless you have a secure automatic revocation mechanism. And if you have such a mechanism, you don't need Code Signing! because the only way to make sure that a piece of code you're presented with isn't on a revocation list is to check the revocation list when you're presented with it... and if you can do that, why do you need to sign the code? You can directly verify the authenticity and integrity of the code by downloading a checksum instead of a revocation list.
#5) The fact that the evidence of attack (the signature on the code) is stored on the computer under attack is mostly useless: The attack could delete or modify the signature during the attack, or simple reformat the drive where the signature is stored.
My comments: I am not sure what this statement means.
Two things. First, he's pointing out that Code Signing isn't useful for forensics. For example, if someone attacks you using a compromisable signed applet they can remove the evidence that they did it. Secondly and more importantly the signature database becomes a new source of exploits: if you can compromise the signature database, you can sign your exploit code!
Basically, Code Signing is a tool that you can use to reduce the risks incurred by doing something inherently risky: automatically running unrestricted code provided by a potentially untrusted source. There are two reasons you might want to do this: first, because you're concerned with the performance impact of running the untrusted code in a sandbox; second, because you want to avoid the organizational cost of distributing applications to end-users through other mechanisms.
In practice, the performance impact of sandboxing has become a moot point, given the speed of modern computers and the efficiency and capability of scripting languages. The difference between the scripted Google Maps and the native Microsoft Streets and Trips is almost entirely attributable to the difference between remote and local map storage. The user interface itself is similarly smooth and responsive when you're not hitting the network.
As for distribution, the complexity and the amount of manual work involved in making sure each computer is configured to securely allow appropriate signed applets to run without opening up security holes is significant. I find it hard to imagine that distributing software through traditional mechanisms would not be an improvement. Even Microsoft's Software Update requires at least one manual verification step the first time you use it that comparable update mechanisms that use individual package signatures (hashes) manage to avoid.
And it doesn't implement secure automatic revocation, which means that if you find an exploit in a signed package you can continue to use that package as part of an exploit... if the package had to be explicitly downloaded from a secure server, or if a hash of the package had to be fetched from a secure server before it was accepted, then this attack mechanism wouldn't exist.
So... deploying signed code reduces security when compared to explicitly installed code or checksummed packages: it opens you up for attacks from old versions of the package, and it opens you up to attacks that compromise the local signature database.
Which is why Schnier brings up these points... it's not that these are attacks that Code Signing is supposed to prevent, rather they're attacks that Code Signing makes easier.
Running a 64bit processor on a 32bit OS (forcing 32bit software) is as bad as running 32bit software on a 64bit OS
Yes, but that could be anything from "very bad indeed" to "it actually runs faster" depending on the hardware. On the Alpha trapping unaligned accesses will kill you, but on most RISCs you're usually better off in 32-bit mode if you don't need the larger address space.
The performance difference between running Windows 32bit and Windows 64bit with 64bit applications IS significant
You have no way of knowing that unless you've implemented both a 32-bit and 64-bit Windows using the same instruction set architecture, because Microsoft hasn't done that for you. Heck, they don't even give you the option of really using either 32 and 64 bit models using the AMD64 ISA. The only tests that have been done have been between the AMD64 ISA and the IA32 ISA on the AMD64 hardware, and the larger register file on AMD64 completely swamps any effects the word size might have on performance.
And, in fact, Windows in 64-bit mode is far from a pure 64-bit model. Most of the word sizes are the same as in 32-bit mode, and unless an application has been redesigned to use the new 64-bit types it's still effectively a 32-bit application. It has a larger address space, but I for one would be extremely reluctant to use it without auditing the whole program for pointer/index truncation bugs.
Read the discussion here...
A GSM/GPRS/UMTS phone, preferably one that takes two SIMs, allowing it to listen on two networks simultaneously. Quadband and UMA support would beperfect
A 3 megapixel Kodak-quality camera
The ability to act as an 802.11g peer or hub, with the machine showing up as a basic server on the network that you can just copy files to and from, plus network routing for when the phone's in GPRS/etc mode.
A 10G (or better) mini-HD, so I can store all my music rather than have to decide what music I'm going to listen to in advance
Good MP3 and Ogg support
Standardized 2.5mm handsfree and 3.5mm stereo headset jacks
Openable to reveal a landscape touchscreen plus a minikeyboard
Don't forget:Personally, I want my old Nokia back, with its monochrome screen and no data service or ringtones and enough battery life that I could use it for a whole long weekend without charging or rationing...
While it would be nice to have tabs and a search box in IE, those are not the features of Firefox that make me use it. If you did something like "block ActiveX in IE", you'd get close, but then all those things that require IE wouldn't work.
Copy the MS HTML control, binary patch the copy so it has its own registry keys and profile and doesn't get confused with the original. That includes its own HKEY_CLASSES_ROOT!
Using these patched keys, configure it so it will ONLY run ActiveX controls from %SYSTEMROOT%\system32\%GENSYM%\chrome - I guess it might be safe to make everything not in that directory "internet zone" and set its version of "internet zone" to disable scripting, the whole kit and caboodle.
Now you can copy the controls you know are safe to use and necessary for to function as a web browser into that directory, and put a bare minimum of applications in its HKEY_CLASSES_ROOT.
Then patch the IE "shell" and Outlook to use this control.
Windows owns around a 95% marketshare and Macintosh has around a 1.9%, and Linux has around a 2%. Please note that I am talking client not server OS.
Where are you getting these numbers?
The Mac market share in the use for 4Q04 was 2.9%, for 1Q05 3.7%. That's higher than IBM/Lenovo.
Linux is harder to measure, but it's not strong on the desktop. Servers, yes, but desktops? A year ago it was pushing close to Apple, 2.8% to 2.9% if I'm reading IDC's summary right, and if Apple loses market share over the Intel switch it may briefly surpass the Mac... but there's no way it's matched the 45% year-over-year growth that Apple's currently enjoying.
A $200 premium on a $500 computer is sort of serious.
You only say that because you're not used to paying a 100% "Mac Tax".
Apple's gross margins are generally reported as being about 40%. They're possibly lower than that on the mini... last time I priced a generally comparable PC it was only $150 less.
Dell's margins may be negative in some cases, if you don't finance.
That's why Apple can support developing their own OS, and I find that a worthwhile tradeoff.
Avalon / Xaml replaces how you create user interfaces.
It might replace how you create user interfaces, but using a metalanguage like XML or the Tk layout engine has been pretty ordinary stuff elsewhere for a long time.
I won't be managing my data in WinFS this decade. Throw my data into another Windows-specific honeytrap? No thanks.
DotNET? Yet another patch on the proven-unfixable "Security Zones" model that Microsoft's been failing to implement securely since 1997? No thanks.
Really now, how often do you use windows file search to locate something?
Couple of times a day. Well... to try and locate it, anyway.
Finder already does a better job in Jaguar or Panther.
re-engineering to provide functionality while reducing attack surface
Does this mean they're replacing "Security Zones" with a local security model that actually works?
The people who need 64 bit are already using 64-bit. They're doing it because they have to, because they're getting an advantage from the larger words and address spaces to counter the performance hit of throwing up to twice as much data around to do anything.
Alpha and AMD64 are not counterexamples. Alpha got its performance boost from a better overall architecture. AMD64 boxes are not getting a performance win from the 64-bitness of the code, but more from the larger register file. You don't need "pure 64-bit" to get this.
it still does it better than windows for a mere $1,000 more than your silly little white box.
The "Mac Tax" on the mini is below $200.
the article mentions the 'low end' systems will continue to use PPC chips
They probably pulled that statement out of the same hole someone pulled "the 'low end' systems will be the first to switch to Intel" out of.
Nobody knows, outside of Apple and such suppliers they have under NDA.
But I have a playlist called "unambient" for stuff that I don't want to show up in party shuffle.
So I'm actually feeding party shuffle from "playlist is weighted and playlist is not unambient".
You can use a dynamic (smart and updated continuously) playlist to get that effect, by using "Limit to songs selected by play count".
I find this doesn't work all that well, because there's positive feedback in it. If I selected songs manually more often that would work better, but I don't do that.
I have found that I get interesting results by loading my iPod shuffle with a selection from my weighted playlist selected by LEAST often played.
The only time I hear a song twice in the same day is when I have two versions of it.
That's because I use a dynamic playlist with "last played is > 24 hours ago" as one of the rules.