Often, in this case, it's not just multiple OSes that need to access the filesystem, but also embedded devices. Think digital cameras, GPSes, that sort of thing, where the overhead of a journaling filesystem is pretty overkill, but it still needs to be accessed by full-blown OSes.
FAT is perfect for those devices, due to its lack of features.
MS wasn't the company chasing a "do-it-all" filesystem.
The fact of the matter is, FAT is the only filesystem that every mainstream platform supports, and you'll lose a lot of market if you don't support FAT. The sole exception that I can think of... iPods are HFS+ by default, but when you use them on a Windows machine, they get reformatted as FAT.
LocalSystem privilege escalation - basically, schedule an interactive command prompt in the task scheduler, and that will be running at LocalSystem - the highest user level in Windows, higher than root on *nix.
Except, running as administrator, the only times I've seen issues, I don't think LocalSystem could hit it either, it was a file locking issue.
If push really comes to shove, pop in a BartPE live CD. There, you've got access to the filesystem that way.
LVDS isn't encrypted at all, and it's usually how the bare LCD panel is driven - there's usually two (or more, but usually two for logic) PCBs in an LCD display of some kind. One takes inputs (VGA, DVI, HDMI, etc., etc.,) and outputs LVDS. The other takes LVDS and controls the individual pixels.
Not to mention, the LVDS protocols used by LCDs are simpler than TMDS, IIRC - it'd actually be easier to get the content from LVDS instead of DVI/HDMI.
Of course, DisplayPort is pushing for an internal DisplayPort standard, which would give HDCP straight to the controller driving the pixels directly.
I only buy used pre-2005 Sony products, myself. Actually, I think the only Sony product that I bought that has been badged as a Sony was made in 1985. (I do have a few Sony-made, Dell-branded Trinitron monitors from 2000-2001, though.
Oh, and AFAIK, I've never owned a Sony laptop battery.
Actually, all they had to do was go through all of their warranty return keyboards. ThinkPad keys get shiny with use. The shiniest keys are the most used ones.
ReactOS and WINE are actually sharing code where possible. The difference is, WINE is meant to run Windows apps on *nix, ReactOS is a complete Windows operating system with a kernel intended to be 100% compatible with NT 5.2 in API and drivers, and a userland 100% compatible with the current release version of NT (so currently 6.0 (Vista.))
Obviously, there's going to be some overlap in the projects.
...is not RMS-style bitching out people who don't follow his One True Way(tm,) and avoiding things that just work purely because they deviate slightly.
I suspect the best way is to actually use a variation on Microsoft's embrace-extend-extinguish methods.
Here's what that means:
1. Throw support behind ReactOS and Mono. Embrace. 2. Get them to be ~100% compatible with Windows. Extend. 3. Once you've achieved compatibility and feature parity, you'll have control of the API. Add new features that Microsoft doesn't have, in a way that would be very difficult for Microsoft to implement in a real NT kernel. Extinguish.
Hardly. In 2002, RISC OS was a tiny, tiny part of their marketshare. Acorn folded in 1998. That left a few A7000+ clones and then at the end of 2002 the Iyonix, which I don't think moved 50,000 units. Oh, and some Pace set top boxes, but still...
Slashdot Mirror
Often, in this case, it's not just multiple OSes that need to access the filesystem, but also embedded devices. Think digital cameras, GPSes, that sort of thing, where the overhead of a journaling filesystem is pretty overkill, but it still needs to be accessed by full-blown OSes.
FAT is perfect for those devices, due to its lack of features.
Except MS has NTFS for when you need big.
MS wasn't the company chasing a "do-it-all" filesystem.
The fact of the matter is, FAT is the only filesystem that every mainstream platform supports, and you'll lose a lot of market if you don't support FAT. The sole exception that I can think of... iPods are HFS+ by default, but when you use them on a Windows machine, they get reformatted as FAT.
LocalSystem privilege escalation - basically, schedule an interactive command prompt in the task scheduler, and that will be running at LocalSystem - the highest user level in Windows, higher than root on *nix.
Except, running as administrator, the only times I've seen issues, I don't think LocalSystem could hit it either, it was a file locking issue.
If push really comes to shove, pop in a BartPE live CD. There, you've got access to the filesystem that way.
LVDS isn't encrypted at all, and it's usually how the bare LCD panel is driven - there's usually two (or more, but usually two for logic) PCBs in an LCD display of some kind. One takes inputs (VGA, DVI, HDMI, etc., etc.,) and outputs LVDS. The other takes LVDS and controls the individual pixels.
Not to mention, the LVDS protocols used by LCDs are simpler than TMDS, IIRC - it'd actually be easier to get the content from LVDS instead of DVI/HDMI.
Of course, DisplayPort is pushing for an internal DisplayPort standard, which would give HDCP straight to the controller driving the pixels directly.
That article counted the PS3 separately, however. In reality, there are significantly more BD players than HD-DVD players, counting the PS3.
Movies aren't necessary for survival or even a decent quality of life. Just stop buying them.
If you don't mind buying your players and discs from China, there's always CBHD...
Or you just don't sell computers in China. But, as has been mentioned, CCP said that they didn't need to put that on yet.
I only buy used pre-2005 Sony products, myself. Actually, I think the only Sony product that I bought that has been badged as a Sony was made in 1985. (I do have a few Sony-made, Dell-branded Trinitron monitors from 2000-2001, though.
Oh, and AFAIK, I've never owned a Sony laptop battery.
Fair enough.
That said, I've seen many applications of Scroll Lock as "that useless key that can be mapped to something else.)
And, on ThinkPads, Shift-Scroll Lock is Num Lock, so it has a useful use.
Actually, all they had to do was go through all of their warranty return keyboards. ThinkPad keys get shiny with use. The shiniest keys are the most used ones.
Print Screen >>>>> Command-Option-Shift-3 or whatever the combo is to take a screenshot on OS X.
Oh, and Scroll Lock is often used to control KVMs.
Mods: Actually, he may have a point.
IIRC, Canada gets two different keyboard layouts - US English, and French-Canadian. I'm guessing someone accidentally bought a French-Canadian layout.
Er, #1 or #2. Duh.
I believe there may be a hybrid of option #2 and #3 out there... a box that allows you to connect your landlines to your cellphone.
ReactOS and WINE are actually sharing code where possible. The difference is, WINE is meant to run Windows apps on *nix, ReactOS is a complete Windows operating system with a kernel intended to be 100% compatible with NT 5.2 in API and drivers, and a userland 100% compatible with the current release version of NT (so currently 6.0 (Vista.))
Obviously, there's going to be some overlap in the projects.
And there's still some printers that support most DOS programs.
Most Brother lasers support Epson 9 and 24-pin emulation and IBM ProPrinter emulation... even today. Which is nice for a retrocomputing nut like me. :)
Actually, I do recall there's an option to boot a disk image in DOSBox...
...is not RMS-style bitching out people who don't follow his One True Way(tm,) and avoiding things that just work purely because they deviate slightly.
I suspect the best way is to actually use a variation on Microsoft's embrace-extend-extinguish methods.
Here's what that means:
1. Throw support behind ReactOS and Mono. Embrace.
2. Get them to be ~100% compatible with Windows. Extend.
3. Once you've achieved compatibility and feature parity, you'll have control of the API. Add new features that Microsoft doesn't have, in a way that would be very difficult for Microsoft to implement in a real NT kernel. Extinguish.
Slashdot is US-centric, so we're used to shift-'. (Which is the key to the immediate left of a horizontal enter key.)
However, quite a few 6502s and 65C02s were run at 1 MHz, and I think the first ones were 1 MHz anyway.
(I'm thinking of every 8-bit Apple II except for the IIc Plus, just for starters...)
Multitasking (No for both?)
http://www.sics.se/contiki/
Except it's the other way around. The various "smartbook" chip makers (Qualcomm, Freescale, and TI) are pushing Android on these "smartbooks."
Want to know what a smartbook is? Hardware-wise, it's a netbook with an ARM CPU.
What the GP was saying was that running regular Linux would make more sense.
Hardly. In 2002, RISC OS was a tiny, tiny part of their marketshare. Acorn folded in 1998. That left a few A7000+ clones and then at the end of 2002 the Iyonix, which I don't think moved 50,000 units. Oh, and some Pace set top boxes, but still...
Real definition of smartbook: Microsoft wouldn't port Windows 7 to ARM, so we'll run a smartphone OS on an ARM-based netbook, and call it a smartbook.