Someone above mentioned having the alternative of a Linux build on the PC with Windows running in a virtual machine. In my place at least, that wouldn't wash as the firm has a custom desktop build that I expect would have a few problems running in vmware.
Is your custom desktop build tied to specific hardware or something? What makes you think it would not run in a VM?
What doesn't make sense though, is given the energy efficiency and easy-to-read high contrast functionality of E Ink, why other than Motorola with its Motofone, has no other cell phone manufacturer incorporated E Ink technology into its handsets?
Why would it make sense to use e-paper (or e-ink, whichever term you prefer) for cell phones?
How much energy do you think the LCD screen on a cell phone consumes? Keep in mind that for most people, the LCD screens and their backlights are on only a fraction of the time. I would think that most of the energy consumed is by the radio. Also, backlit LCD screens are easy to see in the dark. LCD screens also display color, which is good for camera phones.
That's not to say that e-paper-based displays can't overcome those issues, but I don't think it's there yet. And if an e-paper display isn't cheaper to manufacture than an LCD display (which I assume to be true since it's relatively new), I see no compelling reason for cell phone manufacturers to switch to them right now. Maybe in a few years, though.
Oh come on. Everyone with a TiVo (and even those without) should know that TiVo collects this type of anonymous, aggregate data. Haven't they done that since the beginning? Did you really think they wouldn't provide that data to third parties?
And frankly, I think it's a good thing. You guys bitch and moan when your favorite TV shows get cancelled because the Nielsen families' interests aren't representative of your own. You guys bitch and moan about advertisers not making more interesting commercials. Well, here you have TiVo, making geek-friendly devices collecting television data about shows and commercials that tech enthusiasts actually watch, and now you guys bitch and moan about that too.
Something's not right with these links... is someone just trying to/. their own blog here or am I being redirected? The first link is completely off topic and goes to a post about SoftMac (a Mac emulator)
The first link goes to the weblog itself. The current entry just happens to be about SoftMac. And Raymond Chen has no need to spam Slashdot to advertise his weblog; it's already well-known in Windows-focused programming circles.
You wrote a tail-recursive solution. That's isomorphic to an iterative loop, and is not what I meant by "recursive". In languages that don't provide iteration primitives (or languages where they're not commonly used, e.g. Lisp/Scheme), recursive vs. iterative usually means "non-tail recursive vs. tail-recursive".
Okay, sure, but it sounds like you're making up arbitrary requirements so your problem fits your solution. Your requirements themselves seem purely academic. Fine, you make it so no node is unreachable temporarily, but why would you need that? The pointer manipulations should never fail, so you never should exit the loop prematurely.
First, when most people say "linked list", they often mean singly-linked list. And reversing a singly-linked list is trivial too, but people seem to overthink it and make it harder than it actually is. Reversing a singly-linked list is one of those deceptive problems for which lots of people think they should use recursion but really shouldn't. Recursion actually makes it harder.
If you apply an iterative approach instead, I'm sure you'll find that reversing a singly-linked list is much, much easier. Simply treat the linked list as a stack, and as you pop elements off, push them onto a new stack.
You really shouldn't be wrapping statements in ifs to check for errors in C++, you should be using try/catch blocks.
Argh. No. Where did people get the crazy notion of using try-catch everywhere? From Java? Ugh. You shouldn't be wrapping statements in ifs to check for errors in C++, because you should be using RAII and letting destructors handle cleanup.
The exception system alone makes C++ much more comfortable for me than C.
Ugh. The exception system alone certainly does not make C++ easier to use. If you have code that can throw exceptions, you now have a code with multiple exit points, and you can't tell where they are from a cursory examination!
That said, the exception system combined with C++ destructors make me prefer C++. Exceptions in languages that don't support the RAII idiom require try-catch-finally and make me shudder.
One can only speculate (this is/. after all) how much code VPC/Mac and VPC/Windows share. Point is, this isn't just a case of persuading the existing Mac product to compile for Intel.
Of course it isn't. It's a case of persuading the the Mac product team to write a Cocoa UI for the Intel-based backend, as the backend already exists for VPC for Windows. It's a case of persuading the existing Windows product to compile on a Mac.
You're missing the point. The article's about the effect that those changes have had on all future versions, not just about the changes themselves.
Everybody's in such a rush to yell "DUPE!" they don't bother to read.
Pot. Kettle. Black.
DreamWinkle's summary indicates that's what the article is about, but it's really not. The article just shows a bunch of comparison screenshots and talks about what changed and what didn't, and even then, The Mushroom Kingdom's Doki Doki Panic/SMB2 comparison is more accurate, more thorough, and easier to navigate.
Nonsense. VMware Server is free as in beer. It happens to be in beta right now, but the official version still will be free, and VMware already has publically said so.
If you ask Sony's hardware guys about the iPod, most of them will readily concede that they were soundly thrashed by Apple. iPod is the new Walkman, no doubt. Sony could have competed with Apple if they didn't have the content arms sniping at them throughout the development process (and also if they had let go of certain insane engineers who loved minidisc a little too much).
And also note that if it weren't for trying to protect the music division's interests, minidisc players might have been able compete against the iPod from the beginning before the iPod managed to make inroads. Minidiscs could have taken off worldwide, but Sony's crippling of them ultimately prevented that.
Summary: both languages allow you to write unclear code in common cases. You just cherry-picked one case. Yeah, it'd be nice for both languages to require this to be clear in all cases, but till they do, it's your responsibility as a programmer make it clear, either by coding convention or by comment.
The point is that in C, if you see a pointer being passed as an argument, you know that the callee might mutate it, so yes, you have to investigate that callee's contract. In C++, you never know; you have to investigate all callees.
Yes, the grandparent poster cherry-picked one case, but that doesn't invalidate his point that C++ is more unclear than C in this regard.
What are you talking about? The GP2X has an eight-way digital joystick. Why do you think it is like the Tapwave Zodiac? Because they look alike?
Uh, I did say it looked like a Zodiac, did I not?
Even if the joystick isn't analog and is implemented with eight digital switches, so what? That's not the point; it's still inferior to a four-way directional pad, especially for emulating old NES/SNES games, which is one of their advertised selling points.
The GP2X looks mostly like the Tapwave Zodiac, except it runs Linux instead of Palm OS.
As a Zodiac owner, though, I have to say that running old NES/SNES/etc. emulators on it isn't such a great experience; I'd much prefer a digital four-way directional pad over an analog joystick. I don't imagine the GP2X experience would be much better.
It's a pure command-line tool. A GUI toolbar for starting a user-configurable list of tools would have made that tool a lot more user-friendly and acceptable as a tool for corporate use.
The functionality should have been incorporated in Windows from the beginning as a "Run As..." function and a shortcut property.
Well, some of the functionality is there. If you edit a shortcut's properties in XP, the Shortcut > Advanced button lets you modify the shortcut to run with different credentials. Unfortunately, it's anemic; you can't set the shortcut to use particular credentials, so you instead get prompted every time you run it.
Anyhow, I did download and try this eCondom thing. My opinion is that although DropMyRights is more general, eCondom is way better for dealing with IE specifically. It does seem to address the multiple-entry-point issue I mentioned before (links from other apps that spawn browser windows, typing an URL into the Run box, etc.), which is good. (This is probably why it's tied into IE being the system's default browser, although they likely could fail more gracefully than refusing to work at all.) DropMyRights and eCondom seem like good companions to each other.
I kind of like that eCondom-spawned IE windows have "SAFE" in the titlebar so it's easy to distinguish privileged from unprivileged IE windows. On the other hand, it can give a false sense of security since the title text can be easily spoofed.
How does this compare to Mike Howard's DropMyRights program?
The way DropMyRights works is you run it with the path to the target program as a command-line argument. It then spawns the target program automatically with lower privileges. (Maybe too simple; Mike Howard's implementation doesn't allow for passing command-line arguments to the target program itself, although the code is basic enough that others have made their own implementations.)
The only problem is that although it lets you easily modify the shortcut that starts Internet Explorer, there are plenty of ways to start IE without going through that shortcut. Without doing some registry hacking to change your file and protocol associations, it won't help you if you run, say, Outlook with administrator privileges and click a link in an email.
Does eCondom somehow address this? And if it does, then how does it allow exceptions (like going to Windows Update)?
Sigh. Not that I want to be a Sony apologist, and not that I think too highly of Sony Electronics, but...
Hint: Sony, as a corporation, has adopted the position that they should be able to do whatever they wish to your updateable systems in order to protect their corporate interests.
No, they haven't. Sony Music did. Sony, as a large corporation, has various divisions that don't communicate and operate very well together.
So. You guys still buying Playstations can just shut up about the DRM issues. Sony certianly doesn't care about your opinions. You're still buying their stuff.
The Playstation division is even further removed from the others.
There were people at Sony that approved this technology for use on CDs; they could face jail time. There were people at Sony that knew that their software included a rootkit and insecure kernel modifications, and yet claimed otherwise; they could face fraud charges
I'm not so sure. Do you really think the Sony Music execs truly understood what they approved? Most people don't know what rootkits and kernels are, and I don't think the music execs fully grasped its implications either. I don't think the following is so unlikely:
Sony Music: We want a DRM solution.
First4Internet: Here you go.
Sony Music: And you assure us this works?
First4Internet: Sure.
Sony Music: Okay!
Even if First4Internet explained to them how their system worked, most people aren't very forward-thinking. Lots of people don't really have the imagination or the comprehension to consider the consequences and implications of their actions, especially in the software realm. (Also keep in mind that Sony Music is separate from Sony Electronics, Sony Computer Entertainment, etc.. Do they have a staff of qualified software engineers?) Would it have occurred to any of the Sony Music execs that viruses or other malware could take advantage of this system? I doubt it. I think it's pretty evident they're not that creative.
Sony didn't actually write the infamous DRM/rootkit software.
Sony Electronics is significantly less evil than the music division, and Sony is so large that the divisions really don't know what the others are doing. I bet a lot of the people at Sony Electronics are pretty pissed that the music division (which tied the electronics division's hands and prevented them from making an iPod competitor earlier) is now dragging the entire brand name through the mud.
This isn't anything new. People have been discussing this for a long time. It's pretty well known that GUIs are better for some tasks and CLIs are better for others. Rather than trying to proclaim that one is dead, people really should work on making them work better together.
Anyhow. Until people start making more advances in that arena, in the meantime, I've found that using a keyboard with an integrated TrackPoint works great. (You can find old IBM ones on eBay or get some from pckeyboards.com.) Any modern OS supports multiple input pointing devices, so if you need to do a lot of mousing but only a little bit of typing, you still can have a normal mouse available to you. If, however, you need to do a lot of typing but only a little bit of mousing, you can keep your fingers at your keyboard the whole time. It's the best of both worlds, and I think all keyboards should come like this.
I can't read the article since it's slashdotted, but if you need to design the keying pattern and write your own software, then what are you buying for $25? Why not just make a keying pattern and write software to work with a normal 101/104-key keyboard to give it a one-handed mode?
It seems far more useful to me not to make a keyboard that must be used only with one-hand but to make a two-handed keyboard that allows one-handed use when you need it (the other hand's on the mouse, you dirty thinkers).
Enter OkayKeybees. It lets Windows users define keying chords to make your own one-handed mode. Its GUI is kind of clunky (I found it easier to edit the configuration file with a text editor), and it kind of sucks that you have to define your own key chords (Matias has a patent on their layout).
Usable doesn't mean pretty. Pretty doesn't mean usable. Artists can add aesthetic polish, but if they don't know anything about usability, they'll just make the problem worse. Look at Kai's Power Tools or the various other applications that try to look happy or fun but end up being totally non-standard and difficult to use.
Write your software so that it can be expanded with skins
Skins are not a solution to usability. Skins are a punt. To me, skins represent everything that's wrong: the software developers doesn't feel like spending the effort to time on design and doing usability testing, so they throw on a skin system and let the user deal with it.
How many users actually go create their own customized skins? And most skins out there usually cater more to aesthetics than utility.
Plus, there's the perpetual problem where every application has its own skin, and nothing is consistent with anything else. If necessary, global themes should be used for personalization; per-application skins are a mess.
Write your own GUI widgets instead of dragging and dropping something from your existing library.
Good lord, no. Please, please don't reinvent GUI widgets. Lack of consistency is one of the problems, especially in the OSS world where there are a zillion and one widget toolkits. Do you want a dozen different textboxes where some of them allow copy/paste and some of them inexplicably don't? Or maybe some of them can't handle Unicode, or maybe some of them don't have keyboard shortcuts to select text, or who knows what else.
Standardize. Stop bickering, stop wasting time reinventing things, and then everyone can focus on real usability issues.
Why would it make sense to use e-paper (or e-ink, whichever term you prefer) for cell phones?
How much energy do you think the LCD screen on a cell phone consumes? Keep in mind that for most people, the LCD screens and their backlights are on only a fraction of the time. I would think that most of the energy consumed is by the radio. Also, backlit LCD screens are easy to see in the dark. LCD screens also display color, which is good for camera phones.
That's not to say that e-paper-based displays can't overcome those issues, but I don't think it's there yet. And if an e-paper display isn't cheaper to manufacture than an LCD display (which I assume to be true since it's relatively new), I see no compelling reason for cell phone manufacturers to switch to them right now. Maybe in a few years, though.
Oh come on. Everyone with a TiVo (and even those without) should know that TiVo collects this type of anonymous, aggregate data. Haven't they done that since the beginning? Did you really think they wouldn't provide that data to third parties?
And frankly, I think it's a good thing. You guys bitch and moan when your favorite TV shows get cancelled because the Nielsen families' interests aren't representative of your own. You guys bitch and moan about advertisers not making more interesting commercials. Well, here you have TiVo, making geek-friendly devices collecting television data about shows and commercials that tech enthusiasts actually watch, and now you guys bitch and moan about that too.
You wrote a tail-recursive solution. That's isomorphic to an iterative loop, and is not what I meant by "recursive". In languages that don't provide iteration primitives (or languages where they're not commonly used, e.g. Lisp/Scheme), recursive vs. iterative usually means "non-tail recursive vs. tail-recursive".
Okay, sure, but it sounds like you're making up arbitrary requirements so your problem fits your solution. Your requirements themselves seem purely academic. Fine, you make it so no node is unreachable temporarily, but why would you need that? The pointer manipulations should never fail, so you never should exit the loop prematurely.
First, when most people say "linked list", they often mean singly-linked list. And reversing a singly-linked list is trivial too, but people seem to overthink it and make it harder than it actually is. Reversing a singly-linked list is one of those deceptive problems for which lots of people think they should use recursion but really shouldn't. Recursion actually makes it harder.
If you apply an iterative approach instead, I'm sure you'll find that reversing a singly-linked list is much, much easier. Simply treat the linked list as a stack, and as you pop elements off, push them onto a new stack.
Argh. No. Where did people get the crazy notion of using try-catch everywhere? From Java? Ugh. You shouldn't be wrapping statements in ifs to check for errors in C++, because you should be using RAII and letting destructors handle cleanup.
Ugh. The exception system alone certainly does not make C++ easier to use. If you have code that can throw exceptions, you now have a code with multiple exit points, and you can't tell where they are from a cursory examination!
That said, the exception system combined with C++ destructors make me prefer C++. Exceptions in languages that don't support the RAII idiom require try-catch-finally and make me shudder.
Of course it isn't. It's a case of persuading the the Mac product team to write a Cocoa UI for the Intel-based backend, as the backend already exists for VPC for Windows. It's a case of persuading the existing Windows product to compile on a Mac.
Pot. Kettle. Black.
DreamWinkle's summary indicates that's what the article is about, but it's really not. The article just shows a bunch of comparison screenshots and talks about what changed and what didn't, and even then, The Mushroom Kingdom's Doki Doki Panic/SMB2 comparison is more accurate, more thorough, and easier to navigate.
Nonsense. VMware Server is free as in beer. It happens to be in beta right now, but the official version still will be free, and VMware already has publically said so.
And also note that if it weren't for trying to protect the music division's interests, minidisc players might have been able compete against the iPod from the beginning before the iPod managed to make inroads. Minidiscs could have taken off worldwide, but Sony's crippling of them ultimately prevented that.
The point is that in C, if you see a pointer being passed as an argument, you know that the callee might mutate it, so yes, you have to investigate that callee's contract. In C++, you never know; you have to investigate all callees.
Yes, the grandparent poster cherry-picked one case, but that doesn't invalidate his point that C++ is more unclear than C in this regard.
Uh, I did say it looked like a Zodiac, did I not?
Even if the joystick isn't analog and is implemented with eight digital switches, so what? That's not the point; it's still inferior to a four-way directional pad, especially for emulating old NES/SNES games, which is one of their advertised selling points.
The GP2X looks mostly like the Tapwave Zodiac, except it runs Linux instead of Palm OS.
As a Zodiac owner, though, I have to say that running old NES/SNES/etc. emulators on it isn't such a great experience; I'd much prefer a digital four-way directional pad over an analog joystick. I don't imagine the GP2X experience would be much better.
Someone made a shell extension version, which is a bit friendlier.
Well, some of the functionality is there. If you edit a shortcut's properties in XP, the Shortcut > Advanced button lets you modify the shortcut to run with different credentials. Unfortunately, it's anemic; you can't set the shortcut to use particular credentials, so you instead get prompted every time you run it.
Anyhow, I did download and try this eCondom thing. My opinion is that although DropMyRights is more general, eCondom is way better for dealing with IE specifically. It does seem to address the multiple-entry-point issue I mentioned before (links from other apps that spawn browser windows, typing an URL into the Run box, etc.), which is good. (This is probably why it's tied into IE being the system's default browser, although they likely could fail more gracefully than refusing to work at all.) DropMyRights and eCondom seem like good companions to each other.
I kind of like that eCondom-spawned IE windows have "SAFE" in the titlebar so it's easy to distinguish privileged from unprivileged IE windows. On the other hand, it can give a false sense of security since the title text can be easily spoofed.
How does this compare to Mike Howard's DropMyRights program?
The way DropMyRights works is you run it with the path to the target program as a command-line argument. It then spawns the target program automatically with lower privileges. (Maybe too simple; Mike Howard's implementation doesn't allow for passing command-line arguments to the target program itself, although the code is basic enough that others have made their own implementations.)
The only problem is that although it lets you easily modify the shortcut that starts Internet Explorer, there are plenty of ways to start IE without going through that shortcut. Without doing some registry hacking to change your file and protocol associations, it won't help you if you run, say, Outlook with administrator privileges and click a link in an email.
Does eCondom somehow address this? And if it does, then how does it allow exceptions (like going to Windows Update)?
Sigh. Not that I want to be a Sony apologist, and not that I think too highly of Sony Electronics, but...
No, they haven't. Sony Music did. Sony, as a large corporation, has various divisions that don't communicate and operate very well together.
The Playstation division is even further removed from the others.
I'm not so sure. Do you really think the Sony Music execs truly understood what they approved? Most people don't know what rootkits and kernels are, and I don't think the music execs fully grasped its implications either. I don't think the following is so unlikely:
Sony Music: We want a DRM solution.
First4Internet: Here you go.
Sony Music: And you assure us this works?
First4Internet: Sure.
Sony Music: Okay!
Even if First4Internet explained to them how their system worked, most people aren't very forward-thinking. Lots of people don't really have the imagination or the comprehension to consider the consequences and implications of their actions, especially in the software realm. (Also keep in mind that Sony Music is separate from Sony Electronics, Sony Computer Entertainment, etc.. Do they have a staff of qualified software engineers?) Would it have occurred to any of the Sony Music execs that viruses or other malware could take advantage of this system? I doubt it. I think it's pretty evident they're not that creative.
To be fair:
Ah, the age old debate between GUIs and CLIs.
This isn't anything new. People have been discussing this for a long time. It's pretty well known that GUIs are better for some tasks and CLIs are better for others. Rather than trying to proclaim that one is dead, people really should work on making them work better together.
Anyhow. Until people start making more advances in that arena, in the meantime, I've found that using a keyboard with an integrated TrackPoint works great. (You can find old IBM ones on eBay or get some from pckeyboards.com.) Any modern OS supports multiple input pointing devices, so if you need to do a lot of mousing but only a little bit of typing, you still can have a normal mouse available to you. If, however, you need to do a lot of typing but only a little bit of mousing, you can keep your fingers at your keyboard the whole time. It's the best of both worlds, and I think all keyboards should come like this.
You call that an obligatory quote? "Pitch black", not just "very dark"! Kids these days.
I can't read the article since it's slashdotted, but if you need to design the keying pattern and write your own software, then what are you buying for $25? Why not just make a keying pattern and write software to work with a normal 101/104-key keyboard to give it a one-handed mode?
It seems far more useful to me not to make a keyboard that must be used only with one-hand but to make a two-handed keyboard that allows one-handed use when you need it (the other hand's on the mouse, you dirty thinkers).
Enter OkayKeybees. It lets Windows users define keying chords to make your own one-handed mode. Its GUI is kind of clunky (I found it easier to edit the configuration file with a text editor), and it kind of sucks that you have to define your own key chords (Matias has a patent on their layout).
Usable doesn't mean pretty. Pretty doesn't mean usable. Artists can add aesthetic polish, but if they don't know anything about usability, they'll just make the problem worse. Look at Kai's Power Tools or the various other applications that try to look happy or fun but end up being totally non-standard and difficult to use.
Skins are not a solution to usability. Skins are a punt. To me, skins represent everything that's wrong: the software developers doesn't feel like spending the effort to time on design and doing usability testing, so they throw on a skin system and let the user deal with it.
How many users actually go create their own customized skins? And most skins out there usually cater more to aesthetics than utility.
Plus, there's the perpetual problem where every application has its own skin, and nothing is consistent with anything else. If necessary, global themes should be used for personalization; per-application skins are a mess.
Good lord, no. Please, please don't reinvent GUI widgets. Lack of consistency is one of the problems, especially in the OSS world where there are a zillion and one widget toolkits. Do you want a dozen different textboxes where some of them allow copy/paste and some of them inexplicably don't? Or maybe some of them can't handle Unicode, or maybe some of them don't have keyboard shortcuts to select text, or who knows what else.
Standardize. Stop bickering, stop wasting time reinventing things, and then everyone can focus on real usability issues.
Along the same lines:
The site lists 7061992 and 19920706 among the common numeric passwords.
That can't be a coincidence, can it? What happened on July 6, 1992 that was of such significance?