Windows CE was developed from the ground up as a unique solution for embedded computing. It is not Windows. It is not even Win16 or Win32. Windows CE is its own thing entirely. The only thing Windows CE shares with Windows is source compatibility with most of the Win32 API.
Windows CE will make these miniature laptops shine.
I'm bothered that I didn't think of this before. With all the good press that Linux gets by default, it is nowhere near an embedded OS. Those embedded systems have become more like full computers on account of Linux. Bootstrapping into initrd, ramdisks, yet-another-flash-filesystem, and symlinking everything into/tmp or/mnt/? Feh. Embedded systems don't need them.
I'm glad someone has taken the embedded system development kit and made a target system for these neat laptops.
Oh, and Windows CE also shares device driver APIs with Windows. Talk about ubuiquitous computing from a reliable source.
I was totally unaware of tracemonkey and squirrelfish. Thanks for the pointers! Apache still thinks the multi-process approach works, but I come from a multi-threaded background--talk about high-risk computing! I'm not sure the web needs this, but there are too many bad players that make the multi-process approach necessary. I'm very anxious to learn how they are going to solve the plugin and Java problems.
I'm pretty sure you're talking about Red Flag Linux.
The jewel in this software is V8
on
Google Chrome, Day 2
·
· Score: 5, Insightful
The user interface is limitted and the options available for customization are practically nonexistent based on a somewhat single-sided view from Goodger that browsers should not be customizable. The real value of Chrome is V8, the JavaScript engine, and the smart, asynchronous management of native-code JavaScript objects on the client (without re-parsing them over and over).
V8 will be released to the open source community and hopefully will be the standard JavaScript engine for Firefox which actually has a useful user interface.
I can't really speak of Gears, though, but I think the real value of this release is V8.
Google update service installed without choice
on
Google Chrome, Day 2
·
· Score: 4, Informative
The Goodle update service program is installed without the choice to avoid running it. It is a regular background process started from HKCU\\Software\Microsoft\Windows\CurrentVersion\Run. The files are installed to %HOMEPATH%\Local Settings\Application Data\Google\Update.
By any sensible definition, applications that "phone home" are spyware when they cannot be opted out upon installation. Google Earth's downloader asks you if you want to install it, but Chrome's downloader just goes ahead and sideloads it without asking. Worse, it's not easy to remove, since you have to edit your registry or use a registry "autorun" hacking tool to remove this "phone home" application.
I don't understand Google's motivation for installing this without prompting the user or providing a removal option.
It's not a Windows Service like I originally posted. I amended it to say that the program is running as a regular background process from the registry's "Run" key. It starts every time you log in.
No, this update service is the generic software updater that Google sideloads with Google Earth and other software to update the software packages themselves (and know how many people use the software). Of course I read the comic. It says nothing about sideloaded background processes being installed without the user's consent.
Actually it isn't a service, it's now a regular background process started from HKCU\\Software\Microsoft\Windows\CurrentVersion\Run. Google Earth's downloader asks you if you want to install it, but Chrome's just goes ahead and sideloads it without asking.
AOL had actively promoted an external beta test for the CompuServe 2000 client for Windows that used the Gecko engine but I don't think the AOL client one ever reached external beta. There were some problems with Gecko (circa 2001). Even though its "embeddable," Gecko had so many ways for code to be executed that would hang the hosting application, even if Javascript were disabled. At least part of Javascript has to be enabled in some form for Gecko to work at all. Instant message bombs and email message bombs were a serious problem for AOL members, so they couldn't even use Gecko to render IM and emails. The smallest memory footprint for Gecko was 12 megabytes. It needed someone to implement ART file support which was already available in MSIE--this image compression format, long used by AOL proxies, still mattered in 2001.
When talking about the so-called controlled demolition theory of 7 World Trade, it was only the conspiracy theorists who called it "W-T-C-7" when talking about it.
These buildings were known by a different name in colloquial speech: The building in question was known as "7 World Trade." The others were "1 World Trade" and "2 World Trade" and the like. Never "South Tower" or "W-T-C-Anything."
All this internet-based conspiracism by non-locals has renamed them "WTCx" but they were never known as such to the 400+ men and women who died protecting them on 9/11.
You may have read my comment already but there is an advisory value stored on the card but it's not the authoritative record of the balance. As with the Oyster Card "hacks" in London the cards can be turned off within one day. The central billing system analyzes trending and riders are accepted into the vehicle based on the balance on the card. If that balance doesn't match with the central database the card is turned off within hours. Same happens with cloned cards which can be detected the same way even more quickly as cards are used in impossible locations at impossible time intervals. The vehicle acceptance systems use store-and-forward wireless systems--remember, all the vehicles have onboard radios which will work several times per hour even on routes with the poorest coverage.
I'd like to add that the flamebait posters who've replied to my post might want to investigate how Metrocard works when it comes to accessing the central database in vehicles. I would amend my earlier post to also state that the cards do, indeed, carry the balance of the card, they do not hold the authoritative balance of the card. On vehicles that do not have real-time data links the card's value is used to allow the holder to board the vehicle. The data is checked in a store-and-forward manner (like your local UPS driver's handheld does). If the balance presented by the card and the transaction ID do not match up with the database the card is turned off.
Naturally this doesn't prevent the first or even the second fraudulent fare it certainly blocks the subsequent transactions after the trend is discovered.
Incidentally the vehicles for the newer Smartcard-based systems have real-time data links.
Thought you'd like to know, and maybe try to do some more research, you guys.
The central system provides protection because you can trend activity and fix things afterward. Surely, it doesn't prevent it, but it does allow you to detect it and recover quickly. The stored value mode doesn't allow either, unless, maybe, the central system gets not just the fare paid but the stored value per card ID, and you're tracking that at the central system. And, in that case you might as well be using a central billing system.
Stored value cards are foolish. They should only ever be used for identification and authentication. The value being managed must always be stored and administered on the billing system itself.
This is why the responsible agencies (EZ-Pass, WMATA DC Metro, NYC Metrocard) should not, and usually do not, use stored value cards.
How naive of the MBTA to do this.
Cloning is still a problem with DC Metro and NYC Metrocard, but this is relatively easy to detect using database analysis and trending.
The security should lie with the central system. Stored value cards are never secure--especially if you're depending on the obsolete version of MiFare Classic which should have only ever been used for authentication (serial numbers, keys, and scanned fingerprints).
Never for a so-called "digital purse" like MBTA used it for.
Even though I was moderated "Troll" and most people didn't see the original post, my point still stands and here is the defense.
The whole idea of SSL is to provide mutual authentication via a public key infrastructure (PKI). It was not intended soley to protect the data "in transit" but to, in addition to transport security, provide mutual authentication using PKI.
To say that real SSL certificates are "overkill" for most applications demonstrates a fundamental misunderstanding of the intentions of the SSL protocol. At the very worst it's because you don't want to pay someone to vouch for your server's identity, which is why we have server certificates that are signed by a third party in the first place.
Firefox 3 has taken the right step to protect internet communications by proving with more than just a little confidence that the other end of the connection is whom they say they are. The common misconception is that SSL is just for transport security. This is only one half of the intention of SSL. The other half is to prove to the client that the other side is whom they say they are. The only optional part is the client certificate.
To say that self-signed certificates are valid is the same as saying that fake drivers' licenses are okay. They just are not okay in any circumstance.
Now, if there were an SSL/TLS method that didn't require certificates on the server side, then this argument would be moot. However, the protocol requires the server must be repudiated, and the use of self-signed certificates are a cheap way to cheat the end user out of what SSL is supposed to provide--security for the end user.
The arguments about SSH are not valid in this discussion, but thanks for reminding us how insecure SSH is.
Does anyone remember bowling with the Atari automatic scoring system? I think I played on an Army base in New Jersey in the very early 1980s. Today, automatic scoring is everywhere, but in the early 1980s it was nowhere. It had video screens and even let you print out your frames on paper roll printers.
Awesome, what version of DirectX do I need to download to use it? I needed to get some weird version of DirectX with a letter at the end of it to get the Direct Audio for managed code at all.
That's right, and Microsoft even abandoned most of DirectX for Managed Code (.NET) for some reason. I wonder how much money was toiletted for that effort. That would have been cross-platform.
Slashdot Mirror
You mean you all didn't already know this?
Sorry you didn't take action eight (8) years ago.
Read me: http://ask.slashdot.org/article.pl?sid=00/04/14/1418203
People laughed at my tape drives, too.
The only thing I have to say is watch this:
http://www.youtube.com/results?search_query=street+fighter+the+later+years&search_type=&aq=f
Windows CE was developed from the ground up as a unique solution for embedded computing.
It is not Windows.
It is not even Win16 or Win32.
Windows CE is its own thing entirely.
The only thing Windows CE shares with Windows is source compatibility with most of the Win32 API.
Windows CE will make these miniature laptops shine.
I'm bothered that I didn't think of this before. /tmp or /mnt/? Feh. Embedded systems don't need them.
With all the good press that Linux gets by default, it is nowhere near an embedded OS. Those embedded systems have become more like full computers on account of Linux. Bootstrapping into initrd, ramdisks, yet-another-flash-filesystem, and symlinking everything into
I'm glad someone has taken the embedded system development kit and made a target system for these neat laptops.
Oh, and Windows CE also shares device driver APIs with Windows. Talk about ubuiquitous computing from a reliable source.
I was totally unaware of tracemonkey and squirrelfish. Thanks for the pointers!
Apache still thinks the multi-process approach works, but I come from a multi-threaded background--talk about high-risk computing!
I'm not sure the web needs this, but there are too many bad players that make the multi-process approach necessary.
I'm very anxious to learn how they are going to solve the plugin and Java problems.
I'm pretty sure you're talking about Red Flag Linux.
The user interface is limitted and the options available for customization are practically nonexistent based on a somewhat single-sided view from Goodger that browsers should not be customizable.
The real value of Chrome is V8, the JavaScript engine, and the smart, asynchronous management of native-code JavaScript objects on the client (without re-parsing them over and over).
V8 will be released to the open source community and hopefully will be the standard JavaScript engine for Firefox which actually has a useful user interface.
I can't really speak of Gears, though, but I think the real value of this release is V8.
The Goodle update service program is installed without the choice to avoid running it.
It is a regular background process started from HKCU\\Software\Microsoft\Windows\CurrentVersion\Run.
The files are installed to %HOMEPATH%\Local Settings\Application Data\Google\Update.
By any sensible definition, applications that "phone home" are spyware when they cannot be opted out upon installation.
Google Earth's downloader asks you if you want to install it, but Chrome's downloader just goes ahead and sideloads it without asking. Worse, it's not easy to remove, since you have to edit your registry or use a registry "autorun" hacking tool to remove this "phone home" application.
I don't understand Google's motivation for installing this without prompting the user or providing a removal option.
It's not a Windows Service like I originally posted. I amended it to say that the program is running as a regular background process from the registry's "Run" key. It starts every time you log in.
No, this update service is the generic software updater that Google sideloads with Google Earth and other software to update the software packages themselves (and know how many people use the software).
Of course I read the comic. It says nothing about sideloaded background processes being installed without the user's consent.
Actually it isn't a service, it's now a regular background process started from HKCU\\Software\Microsoft\Windows\CurrentVersion\Run.
Google Earth's downloader asks you if you want to install it, but Chrome's just goes ahead and sideloads it without asking.
AOL had actively promoted an external beta test for the CompuServe 2000 client for Windows that used the Gecko engine but I don't think the AOL client one ever reached external beta.
There were some problems with Gecko (circa 2001).
Even though its "embeddable," Gecko had so many ways for code to be executed that would hang the hosting application, even if Javascript were disabled. At least part of Javascript has to be enabled in some form for Gecko to work at all. Instant message bombs and email message bombs were a serious problem for AOL members, so they couldn't even use Gecko to render IM and emails.
The smallest memory footprint for Gecko was 12 megabytes.
It needed someone to implement ART file support which was already available in MSIE--this image compression format, long used by AOL proxies, still mattered in 2001.
Am I the only one whose Windows computer is now running a service called "Google Update" which I was not asked to have installed?
I don't understand why we are obsessed with regenerating back into the grid.
Localized wind power and solar for individual houses is the right answer.
I mean, I saw it on that "Off the Grid" show on the Green Channel.
When talking about the so-called controlled demolition theory of 7 World Trade, it was only the conspiracy theorists who called it "W-T-C-7" when talking about it.
These buildings were known by a different name in colloquial speech:
The building in question was known as "7 World Trade." The others were "1 World Trade" and "2 World Trade" and the like. Never "South Tower" or "W-T-C-Anything."
All this internet-based conspiracism by non-locals has renamed them "WTCx" but they were never known as such to the 400+ men and women who died protecting them on 9/11.
.
You may have read my comment already but there is an advisory value stored on the card but it's not the authoritative record of the balance. As with the Oyster Card "hacks" in London the cards can be turned off within one day. The central billing system analyzes trending and riders are accepted into the vehicle based on the balance on the card. If that balance doesn't match with the central database the card is turned off within hours. Same happens with cloned cards which can be detected the same way even more quickly as cards are used in impossible locations at impossible time intervals. The vehicle acceptance systems use store-and-forward wireless systems--remember, all the vehicles have onboard radios which will work several times per hour even on routes with the poorest coverage.
I'd like to add that the flamebait posters who've replied to my post might want to investigate how Metrocard works when it comes to accessing the central database in vehicles. I would amend my earlier post to also state that the cards do, indeed, carry the balance of the card, they do not hold the authoritative balance of the card. On vehicles that do not have real-time data links the card's value is used to allow the holder to board the vehicle. The data is checked in a store-and-forward manner (like your local UPS driver's handheld does). If the balance presented by the card and the transaction ID do not match up with the database the card is turned off.
Naturally this doesn't prevent the first or even the second fraudulent fare it certainly blocks the subsequent transactions after the trend is discovered.
Incidentally the vehicles for the newer Smartcard-based systems have real-time data links.
Thought you'd like to know, and maybe try to do some more research, you guys.
The central system provides protection because you can trend activity and fix things afterward.
Surely, it doesn't prevent it, but it does allow you to detect it and recover quickly.
The stored value mode doesn't allow either, unless, maybe, the central system gets not just the fare paid but the stored value per card ID, and you're tracking that at the central system. And, in that case you might as well be using a central billing system.
Stored value cards are foolish.
They should only ever be used for identification and authentication.
The value being managed must always be stored and administered on the billing system itself.
This is why the responsible agencies (EZ-Pass, WMATA DC Metro, NYC Metrocard) should not, and usually do not, use stored value cards.
How naive of the MBTA to do this.
Cloning is still a problem with DC Metro and NYC Metrocard, but this is relatively easy to detect using database analysis and trending.
The security should lie with the central system.
Stored value cards are never secure--especially if you're depending on the obsolete version of MiFare Classic which should have only ever been used for authentication (serial numbers, keys, and scanned fingerprints).
Never for a so-called "digital purse" like MBTA used it for.
Even though I was moderated "Troll" and most people didn't see the original post, my point still stands and here is the defense.
The whole idea of SSL is to provide mutual authentication via a public key infrastructure (PKI). It was not intended soley to protect the data "in transit" but to, in addition to transport security, provide mutual authentication using PKI.
To say that real SSL certificates are "overkill" for most applications demonstrates a fundamental misunderstanding of the intentions of the SSL protocol. At the very worst it's because you don't want to pay someone to vouch for your server's identity, which is why we have server certificates that are signed by a third party in the first place.
Firefox 3 has taken the right step to protect internet communications by proving with more than just a little confidence that the other end of the connection is whom they say they are. The common misconception is that SSL is just for transport security. This is only one half of the intention of SSL. The other half is to prove to the client that the other side is whom they say they are. The only optional part is the client certificate.
To say that self-signed certificates are valid is the same as saying that fake drivers' licenses are okay. They just are not okay in any circumstance.
Now, if there were an SSL/TLS method that didn't require certificates on the server side, then this argument would be moot. However, the protocol requires the server must be repudiated, and the use of self-signed certificates are a cheap way to cheat the end user out of what SSL is supposed to provide--security for the end user.
The arguments about SSH are not valid in this discussion, but thanks for reminding us how insecure SSH is.
.
Does anyone remember bowling with the Atari automatic scoring system?
I think I played on an Army base in New Jersey in the very early 1980s.
Today, automatic scoring is everywhere, but in the early 1980s it was nowhere. It had video screens and even let you print out your frames on paper roll printers.
It really shouldn't be an issue whatsoever.
Self-signed certificates are not secure!!
If your web site uses them, then you are not secure.
If you're going to self-sign your certs, why are you even bothering with SSL in the first place?
It's really astounding that people think self-signed certs are a good idea.
Do you even know what SSL is for?
I think the Spanish peasants (in Spain) speaking with Mexican Spanish accents cancelled out the violence.
Kriston
Awesome, what version of DirectX do I need to download to use it?
I needed to get some weird version of DirectX with a letter at the end of it to get the Direct Audio for managed code at all.
Kriston
Find your local Freecycle chapter.
People will take anything you give them.
See http://www.freecycle.org/
Kriston
That's right, and Microsoft even abandoned most of DirectX for Managed Code (.NET) for some reason. I wonder how much money was toiletted for that effort. That would have been cross-platform.
Sorta.