My Commodore 64 and my first Amiga both came with big fat manuals that included schematics.
Unfortunately, for the basement cloner, both systems used custom ICs built by Commodore's MOS Technologies division.
Fortunately, the machines were cheap enough that there wasn't much call for clones. And the custom chips gave the Amiga a performance edge over everything else for a couple of years. The custom ICs in the 64 weren't so much about performance as cost--replacing 74-series TTL chips with a pair of PLAs, the SID and VIC-II chips, and the fairly-sophisticated-for-the-time CIA chips.
Which doesn't explain why serial I/O on both machines was handled in such a boneheaded way. Async serial on the 64 was run of the non-maskable interrupt line on the CPU; entirely timed in software. No use of hardware shifters; there wasn't a UART anywhere on the machine. (There was a synchronous serial port, which was noticably NOT used for the floppy/printer port--that was also all done in software.)
The Amiga at least had UARTs, so the hardware handled start/data/parity/stop in async serial I/O... but the hardware flow control (RTS/CTS) was done in software!
Ooops, that's not the point....
Anyway, even though there wasn't much point in building a Commodore machine from parts, you could sure have a lot of fun with a soldering iron, some TTL chips, and one of those schematics.
Just because someone in power does something illegal, that doesn't negate the law, they just hold themselves out to reprimand or reversal.
The phrases you're looking for are "chilling effect" and "lawyer's fees".
Another problem, that is not restricted to young people, is failing to identify a false authority. (For example, asking the police a question about a point of law.)
Do you find that people don't realize the right-button brings up a context-sensitive menu?
I've found a lot of non-techies don't understand why the menu changes when you're pointing at different things. (Like, in a web browser, the differences between pointing at a link, a picture, blank space, and so on.)
In some cases, the person didn't realize the the same commands were in an unchanging menu ("Go -> Back" in particular) and could avoid the whole worrying about context.
(Apple allows both Control+Button1 and Button3 to pop context menus. They also strongly suggest that the contextual actions be available some other way; the context menu being an accelerator for more experienced users. I think they picked a good key... "I want to control this thing...".)
Context menus are NOT easy. They're powerful, but if you don't know why Button3 menus are different from the regular ones (top of window or screen, depending), you can get very confused about what's going on.
I can see why people like having TVs in the kitchen, as it gives them something to watch when they're cooking, but if I'm in the kitchen, I am cooking. Anything that takes long enough to prepare, to make this worthwhile, is going to be messy enough that I'd have to wash and dry my hands everytime I wanted to use the keyboard/mouse.
When I get the Mini, I'm thinking of relegating my old iMac (tube-type G3) to the kitchen. It has DVD playback (I don't watch a lot of TV) and WiFi; so it might be useful.
Of course, I'm also thinking of asking the store if it is worth anything in trade on the Mini (a local Apple dealer, no Apple Store in Canada). I'm having trouble imagining a world where "yes" is an answer to that question.
The patent system is to protect a novel and non-obvious implementation of an idea.
This is why you find things that do the same job differently. Like, for example, Delta's "stainless steel ball" and Moen's "ceramic cartridge" single-lever faucets. They get the same job done (adjust both temperature and volume of water with a single handle), but they achieve it through uniquely different methods.
That sort of patent encourages creativity, even if it is just so you don't have to license your competitors patent. (Or, of course, you could always just license it if you don't think it is worth the R&D to come up with a different solution to the problem.)
The problem with software patents is that they are read to cover different approaches to solving the same problem. A patent on a solution to the travelling salesman problem would cover all solutions, not just your algorithm. So, sure, that gets people who just copy your algorithm. But it also gets people who came up with a different solution to the problem. (Though, solutions to an NP-complete problems are probably a special case; as solving one is thought to allow all of them to be solved. Let's ignore that bit for the sake of argument, and assume multiple solutions exist.)
You have no clue about the irony in your post, do you?
Well, despite the irony, as long as AOL does not turn to blocking the NNTP ports, any AOL subscriber who wishes to retain USENET access can use the same methods that some of us already use: Find a USENET service provider that isn't part of your ISP. I'm using supernews, because my ISP's NNTP server is junk.
And are there not web-based USENET services out there also?
You don't need everything provided by your ISP. That's the beauty of the Internet; once you're on, you can access any server that has the features you want.
The only problem is finding out which servers are available....
In 1993, IBM provided the compilers for Apple's new hardware. For a while, Apple Workgroup Servers were merely RS/6000s running AIX with an Apple logo on the front panel.
Rumor has it, at one point IBM was going to port their XL C++ (C Set ++ by then) compiler to Mac OS. (That was, of course, way before OS X, so it would be a massive user interface and library effort--the actual code gen for PowerPC 604 was already complete, for the RS/6000s.)
So, yeah, IBM and Apple have been surprisingly close for a while now. With BSD and X11, I don't know why they don't do a quick build of a lot of their apps--instantly add a new target market. Sure, Cocoa is nicer, but X11 is there and it works and you'll be done.
Of course, I do know from experience that IBM is very reluctant to do a "90%" solution--one that works for 90% of the target customers. They'll kill themselves trying to get that last 10% of function, and spend so much time at it that the 90% has gone to some other vendor, the market has changed, and now no-one cares.
"Click on the icon" apps are in/Applications (by default). The BSD userland directories do not appear in Finder (unless you tweak a text file called "/.hidden").
So you can't even browse to the directory with rsync, emacs, cp, ln, ls, and all the rest. (Well, you can explicitly "go to folder"/bin or/usr/bin or anything else. But you won't find it accidentally.)
You might be surprised at how many USB Audio devices work with Linux. Most of them don't require special drivers, they just register as USB Audio class devices, and then you're ready to go.
Look for something that works with Mac OS X. Very few vendors provide drivers for Mac OS X, they rely on the operating system's generic class drivers. I'd suggest that for people using Windows too; if it only works on Windows, you're likely to be at the mercy of a firm that cannot make decent drivers. If it uses the generic class driver from Windows (or Linux or BSD or Mac or PS2 or...), then there's much less worry about the device failing after your next service pack. And you don't have to worry about Microtech (not the scanner company) making drivers that only work with a particular patch of a particular system revision.
I've used the Griffin iMic quite a lot with Linux. I think I've also hooked up my Edirol UA-3, but it spends most of its time as the patch between the iBook and the hifi.
All you need to do to provide power on USB is put +5V across the right two pins (GND and +5V, not +DATA and -DATA...). That is, if you're not going to bother with the data connection at all, and you're just using the USB power for power. (Some host implementations, in particular some Apples, won't give you the full amp of current unless you do the full USB connection and register your device for high current. I've heard.)
So all the external battery pack needs to do is connect the batteries to the power lines, probably via a voltage regulator.
This does suggest that one could use a USB A-A extension cable and the Belkin auto adapter that comes with their USB "Sync/Charge" cables for palmtop devices to charge the Shuffle from a car.
The files from the iTunes Music Store have DRM. The iPod is able to play these files.
Wasn't a firmware update required to support the protected AAC files when iTMS first opened? Looking around at the old updaters, AAC support was added in iPod updater 1.3.
So, continuing from the grandparent, the iPod did NOT have DRM on day 1, since the DRM is tied into the AAC support.
In your example, if product C contains code from product A, and you don't own the copyright to this code, then product C must comply with the license product A was licensed under.
Keep in mind that the following idiom will cause product C to contain code from product A:
#include <A/header.h>
So will linking, shared or static. Unless you can link without access to any of the copyrightable files in program A, your library or application will be a derived work.
The Linux kernel provides an exemption, allowing programs to use standard system calls without becoming a derived work.
Unless the certificate is signed by an authority known to the browser, the browser will issue a warning, and while the average user might click through for unsigned certificates for "pr0n.net" or "fredsdiscountshop.com", they're sure as damn it not going to for their online banking.
That's the weakness, though.
If you trick someone into adding the new signing authority, you've got them. That is, to be sure, more work that just hoping they'll click through the "Site certified by unknown authority" dialog.
But it won't take much social engineering to convince some people to add a new authority certificate if you bait them with free pr0n, or the wonders of a new IE toolbar, or....
Heck, how hard would it be for malware to add a certificate authority?
And if you want to get your cable-count down, either buy some of those cables that have TOSlink or SPDIF bonded to the video cable, or use some tie-wraps to join the two.
I've been doing that for years so it's easier to pull a single component out of the rack.
My experience with Apple warranty service is similar. Though, we don't have any Apple stores in Canada, so they can't do that bit.
When I got my G3 iBook a couple of years ago, it wouldn't work with my 10/100 Ethernet switch at 100 Mbps. Not thinking too carefully, I called up Apple, they couriered out a return box, it went back. When it came back to me, the "corrective action" said "reset PRAM". Mac owners know about this: you power on with CMD-OPT-P-R and it resets the parameter RAM settings to default.
Not surprisingly, it still didn't work with the Ethernet switch... so I put together a crossover cable, and did a few tests (that I should have done in the first place, and I'm kind of surprised Apple didn't suggest). Sure enough, the machine worked fine connected directly to my other machines; I took it in to the office, and it worked fine on several switches there.... Turns out my 10/100 switch was the problem. (And its warranty expires soon, so I really should get it fixed.)
Picked up a new switch on the way home, everything's good now.
But the point is: Apple was well within their rights to return it as "No trouble found" with a diagnosis charge. That's what the warranty terms say, after all. But, instead, they did a "harmless" repair procedure, and covered it under the warranty.
I'm not quite so happy about having had to send it in (twice) under the Logic Board Repair Extension Program, but, again, they don't have to be doing that for free under the warranty terms.
If you're getting the shaft from a low level tech for a legitimate issue[...] then you need to escalate the call.
We're talking about ordinary users who don't know what's a legitimate issue here. If the support guy says, "You changed it, now the warranty is void", what is Joe User going to do?
He's going to take the support-droid's word, as a representative of Dell, that this is really the case. He doesn't know it's bullshit; after all, if he knew what did and didn't matter, he probably wouldn't have had to make the call in the first place.
It's not limited to computers, either.
Ever taken a car to one of those quick-muffler-change shops for the "free estimate"? They'll almost always tell you that you need a new muffler. If you ask, they'll show you a small, neat hole in the bottom of the muffler.
If you know how the exhaust system works or at least what gases are produced in the engine, you'll know that's the condensation drainage hole. But if you don't, and an expert you brought the car to for a professional opinion tells you there's something wrong... well, plenty of people fall for it.
Dell's blame comes into this because they represent Microsoft. It's the OEM edition of Windows; Dell's customers are not Microsoft customers (unless they bought something from MS on their own). Dell sells you a complete system. They should provide you with the tools and information required to keep it working correctly.
If Microsoft makes providing that knowledge or the tools difficult or impossible, that still does not absolve Microsoft OEMs of any responsibility. They're selling a complete product--a home PC. If you want Microsoft to bear full responsibility, then Dell and friends need to stop pre-loading the system, and provide you with a sealed box from Microsoft. "Here, we got you a good deal on Windows with your new PC, but it is provided by Microsoft, not Dell, so you will need to install it from them."
But that would require a major change to the OEM contract--right now, OEMs must support OEM Windows themselves. Microsoft only supports retail copies.
I think the important things about UNIX, aside from having the same libc.a APIs everywhere, is the filesystem.
To have a UNIX-like system, you need:
Single filesystem tree
Transparent mounting of filesystems into the tree
"Everything is a file" approach, all I/O types use the same APIs; so you only need special code for doing special things. (So "cat" can read from magnetic tape, raw disk, or a FIFO; but if you want to rewind the tape, you need a program that knows about it.)
Regular files
Directories
Sockets (TCP, UNIX, NetBEUI, AppleTalk, IPX/SPX--the difference is only in the names you use to open them)
FIFOs
Device-specials
fork(2)/exec(2)/wait(2) process model
"File mode" permission model (something that can be done with bitmasks), as opposed to an "Access Control List" model. (ACLs are available on many UNIXes, but very few programs support them. The OS still enforces them, but (say) "cp" won't preserve the ACL unless you update it.)
With those basic attributes, most batch UNIX programs stand a fair chance of working well.
I've worked on systems which implement only a few of them. Porting a UNIX combined file-and-network program to Windows is a massive pain, because the TCP sockets are not in the same identifier-space a s file handles--so you need to handle them separately. Similarly, any system which doesn't have "fork()" means you have to re-write all your co-processing code. AS/400's POSIX interface is particularly misleading--even more so than Windows. On Windows, you can at least run Windows.exe files fairly normally from the POSIX API; but on OS/400, non-POSIX stuff just doesn't work right (or didn't, back in 1997 when I last had to deal with it).
Even when there seems to be a good alternative, it may not work out well after all. So you can't fork()/exec() on Windows... well, so what, you just want to run a program and wait for it to exit, right? So spawn() is good enough, or CreateProcessEx() if you want more control.
But, launching a new process is very expensive on Windows; a make or shell program will be 10x to 100x slower on Windows than on a UNIX-ish system running on the same machine. When you write native Windows applications, you just don't code that way--you use threads, you use DLLs, you do everything you can in the same process image. You do NOT run external programs if you can help it. (You can, of course, do this on UNIX too if you like; but you don't have to....)
So even having [part of] the interface isn't going to save your code--if your application uses features which aren't handled well, or are simulated, it's going to suck on that system.
Slashdot Mirror
I take it you've never seen the message,
during an installation of Windows NT 3.51 or 4.0?
It wouldn't nuke your OS/2 partition, but it would yank the boot manager off the system AND not give you any way to boot back into your other OS.
If you installed OS/2 after Windows, it would be quite happy to launch the Windows boot manager as one of the sub-items.
Ugh. I wish I could forget this stuff.
Fortunately, the machines were cheap enough that there wasn't much call for clones. And the custom chips gave the Amiga a performance edge over everything else for a couple of years. The custom ICs in the 64 weren't so much about performance as cost--replacing 74-series TTL chips with a pair of PLAs, the SID and VIC-II chips, and the fairly-sophisticated-for-the-time CIA chips.
Which doesn't explain why serial I/O on both machines was handled in such a boneheaded way. Async serial on the 64 was run of the non-maskable interrupt line on the CPU; entirely timed in software. No use of hardware shifters; there wasn't a UART anywhere on the machine. (There was a synchronous serial port, which was noticably NOT used for the floppy/printer port--that was also all done in software.)
The Amiga at least had UARTs, so the hardware handled start/data/parity/stop in async serial I/O... but the hardware flow control (RTS/CTS) was done in software!
Ooops, that's not the point....
Anyway, even though there wasn't much point in building a Commodore machine from parts, you could sure have a lot of fun with a soldering iron, some TTL chips, and one of those schematics.
The phrases you're looking for are "chilling effect" and "lawyer's fees".
Another problem, that is not restricted to young people, is failing to identify a false authority. (For example, asking the police a question about a point of law.)
I've found a lot of non-techies don't understand why the menu changes when you're pointing at different things. (Like, in a web browser, the differences between pointing at a link, a picture, blank space, and so on.)
In some cases, the person didn't realize the the same commands were in an unchanging menu ("Go -> Back" in particular) and could avoid the whole worrying about context.
(Apple allows both Control+Button1 and Button3 to pop context menus. They also strongly suggest that the contextual actions be available some other way; the context menu being an accelerator for more experienced users. I think they picked a good key... "I want to control this thing...".)
Context menus are NOT easy. They're powerful, but if you don't know why Button3 menus are different from the regular ones (top of window or screen, depending), you can get very confused about what's going on.
When I get the Mini, I'm thinking of relegating my old iMac (tube-type G3) to the kitchen. It has DVD playback (I don't watch a lot of TV) and WiFi; so it might be useful.
Of course, I'm also thinking of asking the store if it is worth anything in trade on the Mini (a local Apple dealer, no Apple Store in Canada). I'm having trouble imagining a world where "yes" is an answer to that question.
The patent system is to protect a novel and non-obvious implementation of an idea.
This is why you find things that do the same job differently. Like, for example, Delta's "stainless steel ball" and Moen's "ceramic cartridge" single-lever faucets. They get the same job done (adjust both temperature and volume of water with a single handle), but they achieve it through uniquely different methods.
That sort of patent encourages creativity, even if it is just so you don't have to license your competitors patent. (Or, of course, you could always just license it if you don't think it is worth the R&D to come up with a different solution to the problem.)
The problem with software patents is that they are read to cover different approaches to solving the same problem. A patent on a solution to the travelling salesman problem would cover all solutions, not just your algorithm. So, sure, that gets people who just copy your algorithm. But it also gets people who came up with a different solution to the problem. (Though, solutions to an NP-complete problems are probably a special case; as solving one is thought to allow all of them to be solved. Let's ignore that bit for the sake of argument, and assume multiple solutions exist.)
Well, despite the irony, as long as AOL does not turn to blocking the NNTP ports, any AOL subscriber who wishes to retain USENET access can use the same methods that some of us already use: Find a USENET service provider that isn't part of your ISP. I'm using supernews, because my ISP's NNTP server is junk.
And are there not web-based USENET services out there also?
You don't need everything provided by your ISP. That's the beauty of the Internet; once you're on, you can access any server that has the features you want.
The only problem is finding out which servers are available....
You're getting ahead of yourself with the wireless. It was really:
Smaller than a PDP-11. No thicknet. No TTYs. Lame.
In 1993, IBM provided the compilers for Apple's new hardware. For a while, Apple Workgroup Servers were merely RS/6000s running AIX with an Apple logo on the front panel.
Rumor has it, at one point IBM was going to port their XL C++ (C Set ++ by then) compiler to Mac OS. (That was, of course, way before OS X, so it would be a massive user interface and library effort--the actual code gen for PowerPC 604 was already complete, for the RS/6000s.)
So, yeah, IBM and Apple have been surprisingly close for a while now. With BSD and X11, I don't know why they don't do a quick build of a lot of their apps--instantly add a new target market. Sure, Cocoa is nicer, but X11 is there and it works and you'll be done.
Of course, I do know from experience that IBM is very reluctant to do a "90%" solution--one that works for 90% of the target customers. They'll kill themselves trying to get that last 10% of function, and spend so much time at it that the 90% has gone to some other vendor, the market has changed, and now no-one cares.
"Click on the icon" apps are in /Applications (by default). The BSD userland directories do not appear in Finder (unless you tweak a text file called "/.hidden").
So you can't even browse to the directory with rsync, emacs, cp, ln, ls, and all the rest. (Well, you can explicitly "go to folder" /bin or /usr/bin or anything else. But you won't find it accidentally.)
Look for something that works with Mac OS X. Very few vendors provide drivers for Mac OS X, they rely on the operating system's generic class drivers. I'd suggest that for people using Windows too; if it only works on Windows, you're likely to be at the mercy of a firm that cannot make decent drivers. If it uses the generic class driver from Windows (or Linux or BSD or Mac or PS2 or ...), then there's much less worry about the device failing after your next service pack. And you don't have to worry about Microtech (not the scanner company) making drivers that only work with a particular patch of a particular system revision.
I've used the Griffin iMic quite a lot with Linux. I think I've also hooked up my Edirol UA-3, but it spends most of its time as the patch between the iBook and the hifi.
So all the external battery pack needs to do is connect the batteries to the power lines, probably via a voltage regulator.
This does suggest that one could use a USB A-A extension cable and the Belkin auto adapter that comes with their USB "Sync/Charge" cables for palmtop devices to charge the Shuffle from a car.
Wasn't a firmware update required to support the protected AAC files when iTMS first opened? Looking around at the old updaters, AAC support was added in iPod updater 1.3.
So, continuing from the grandparent, the iPod did NOT have DRM on day 1, since the DRM is tied into the AAC support.
Keep up that attitude and enter anyway. I won two 20 GB iPods in the Pepsi Canada iPod-an-hour giveaway late last year.
I didn't really believe I'd won until I actually had the iPod in my hands.
You know, this sort of thing is exactly where he got started? Being stuck with closed AND broken software that no-one would fix?
What's the difference if it's an outsourcing firm delivering binaries, or a vendor providing a "solution", or a simple application?
Keep in mind that the following idiom will cause product C to contain code from product A: #include <A/header.h>
So will linking, shared or static. Unless you can link without access to any of the copyrightable files in program A, your library or application will be a derived work.
The Linux kernel provides an exemption, allowing programs to use standard system calls without becoming a derived work.
That's the weakness, though.
If you trick someone into adding the new signing authority, you've got them. That is, to be sure, more work that just hoping they'll click through the "Site certified by unknown authority" dialog.
But it won't take much social engineering to convince some people to add a new authority certificate if you bait them with free pr0n, or the wonders of a new IE toolbar, or....
Heck, how hard would it be for malware to add a certificate authority?
Don't know if you're kidding, but I've still got the "Apple logo" stickers that came with my Performa and iMac DV.
I don't think they include stickers with the systems anymore. More cost-cutting, I guess.
The controls on the surface of the case are not fastened to the contacts they operate.
So, [it looks like] you can slide the circuit board out from underneath the buttons without first removing them.
I've been doing that for years so it's easier to pull a single component out of the rack.
When I got my G3 iBook a couple of years ago, it wouldn't work with my 10/100 Ethernet switch at 100 Mbps. Not thinking too carefully, I called up Apple, they couriered out a return box, it went back. When it came back to me, the "corrective action" said "reset PRAM". Mac owners know about this: you power on with CMD-OPT-P-R and it resets the parameter RAM settings to default.
Not surprisingly, it still didn't work with the Ethernet switch... so I put together a crossover cable, and did a few tests (that I should have done in the first place, and I'm kind of surprised Apple didn't suggest). Sure enough, the machine worked fine connected directly to my other machines; I took it in to the office, and it worked fine on several switches there.... Turns out my 10/100 switch was the problem. (And its warranty expires soon, so I really should get it fixed.)
Picked up a new switch on the way home, everything's good now.
But the point is: Apple was well within their rights to return it as "No trouble found" with a diagnosis charge. That's what the warranty terms say, after all. But, instead, they did a "harmless" repair procedure, and covered it under the warranty.
I'm not quite so happy about having had to send it in (twice) under the Logic Board Repair Extension Program, but, again, they don't have to be doing that for free under the warranty terms.
Or is it the audience the RIAA brings? Records, tapes, CDs, radio play and concert venues bigger than your local club?
We're talking about ordinary users who don't know what's a legitimate issue here. If the support guy says, "You changed it, now the warranty is void", what is Joe User going to do?
He's going to take the support-droid's word, as a representative of Dell, that this is really the case. He doesn't know it's bullshit; after all, if he knew what did and didn't matter, he probably wouldn't have had to make the call in the first place.
It's not limited to computers, either.
Ever taken a car to one of those quick-muffler-change shops for the "free estimate"? They'll almost always tell you that you need a new muffler. If you ask, they'll show you a small, neat hole in the bottom of the muffler.
If you know how the exhaust system works or at least what gases are produced in the engine, you'll know that's the condensation drainage hole. But if you don't, and an expert you brought the car to for a professional opinion tells you there's something wrong... well, plenty of people fall for it.
Dell's blame comes into this because they represent Microsoft. It's the OEM edition of Windows; Dell's customers are not Microsoft customers (unless they bought something from MS on their own). Dell sells you a complete system. They should provide you with the tools and information required to keep it working correctly.
If Microsoft makes providing that knowledge or the tools difficult or impossible, that still does not absolve Microsoft OEMs of any responsibility. They're selling a complete product--a home PC. If you want Microsoft to bear full responsibility, then Dell and friends need to stop pre-loading the system, and provide you with a sealed box from Microsoft. "Here, we got you a good deal on Windows with your new PC, but it is provided by Microsoft, not Dell, so you will need to install it from them."
But that would require a major change to the OEM contract--right now, OEMs must support OEM Windows themselves. Microsoft only supports retail copies.
To have a UNIX-like system, you need:
With those basic attributes, most batch UNIX programs stand a fair chance of working well.
I've worked on systems which implement only a few of them. Porting a UNIX combined file-and-network program to Windows is a massive pain, because the TCP sockets are not in the same identifier-space a s file handles--so you need to handle them separately. Similarly, any system which doesn't have "fork()" means you have to re-write all your co-processing code. AS/400's POSIX interface is particularly misleading--even more so than Windows. On Windows, you can at least run Windows .exe files fairly normally from the POSIX API; but on OS/400, non-POSIX stuff just doesn't work right (or didn't, back in 1997 when I last had to deal with it).
Even when there seems to be a good alternative, it may not work out well after all. So you can't fork()/exec() on Windows... well, so what, you just want to run a program and wait for it to exit, right? So spawn() is good enough, or CreateProcessEx() if you want more control.
But, launching a new process is very expensive on Windows; a make or shell program will be 10x to 100x slower on Windows than on a UNIX-ish system running on the same machine. When you write native Windows applications, you just don't code that way--you use threads, you use DLLs, you do everything you can in the same process image. You do NOT run external programs if you can help it. (You can, of course, do this on UNIX too if you like; but you don't have to....)
So even having [part of] the interface isn't going to save your code--if your application uses features which aren't handled well, or are simulated, it's going to suck on that system.