Someone's going to have to explain to me how the statement 'no games like those two have been made since' makes any sense.
Most multiple character RPGs, like the D&D ones such as Baldur's Gate, Neverwinter Nights, Dragon Age, etc, can be operated in 'turn mode' in combat, where you can have the game automatically pause, and direct the exact movement and combat of each person.
For that matter, X-Com was nowhere near the first one. Turn-based tactical games were some of the first computer combat game, and they're still being made...I point to 'Gunrox'.
And I have no idea why you think TIE fighter is some innovative game genre-wise. It's a very very good game, but it is, at heart, a dogfighting (in space) game. There were some before, and there were plenty after. None really as good, but saying 'They don't make dogfighting games like the best one ever made' is just inane...if anything, TIE Fighter has been over-copied.
Yeah, and despite what the estate may think, that renders the first part public domain.
You can make a Sherlock Holmes story if you make it only using pre-1922 sources. Like, oh, the recent movie, which is a new story set at a rather specific time in the Holmes Canon. (When Watson is about to get married and move out.)
And it's worth pointing out that some stuff just isn't copyrightable. If some post-1922 mentions Sherlock Holmes' mother is named 'Nancy' (It doesn't, but let's pretend.), that doesn't make some new work infringes if it just mentions that. If she was some important character in a post-1922 story, and showed up in a new work with the same traits, yeah, that would infringe, but certain things are regarded as background information about the character, and won't infringe.
You want to see an example of this in real life, watch the stage show Wicked, which is based off the public domain book, and not the copyrighted movie. (Actually, it's based of the book Wicked, which is based ff the public domain book.) Despite this, they're able to get away with recreating some of the sets from the movie, and integrating some of the changes from the movie plot in. For example, how the 'Wicked Witch of the East' dies is how she dies in the movie, not the book, including a total recreation of the iconic scene of a house on top of her and the yellow brick road stretching off into the distance. (With Dorothy having just headed down it.)
There's not some absolute 'You can never mention anything about this public domain character that is from stuff still under copyright' rule. They do still, however, have the silver slippers from the book, which is more a shout-out to the book rather than some sort of legal limitation...they could probably get away with ruby ones.
Incidentally, and people don't know this, but Superman is public domain also. There are public domain newsreel-style shorts from the 1930s and 40s with him in them. I don't really know how much of the Superman universe that gets you, though.
With graphics, all they have to do is not map graphics calls, which, hilariously, might mean they need to reconvert the graphic calls that Wine converted into X calls back into Windows API, and, you know, actually send them to the Windows drivers. Hopefully they can just not convert them in the first place, writing a stub module to replace the 'X' one in Wine, instead of having to flop them back and forth.
But they're still left with all the non-driver stuff. Like if there's a Windows function to allocate memory and copy a string into it, Wine figures that out by calling a POSIX function. (And then the POSIX layer in the OS makes a libc call, except on Linux and other glibc OSes where the system calls were intelligently written in POSIX convention to start with, and no one has to do anything.)
Well...they ain't got no POSIX underneath. What are they calling? Wine's entire premise is 'mapping Win API into POSIX and X', and while they might be able to easily change that to 'mapping Win API into POSIX and passing graphics on unchanged', they really do need POSIX to have the thing work at all.
Now, and interesting idea might be to have ReactOS come with glibc. Not for programs running in it to use, just for Wine. Is that what's going to happen, or perhaps already does happen?
I have to disagree with you about 1 and 2, which are clone, but with a very important difference:
They were clones of a bunch of very shitty, incompatible, multiple-vendor things.
At the time, Unix kernels hardly supported any hardware at all. They certainly didn't support standard commodity hardware. (No, Minix was a toy, not a real Unix kernel, before anyone mentions that.) They ran on vendor specific hardware.
And same with the utilities included with them. They were, frankly, horrible. In fact, they're still so crappy that you will find GNU stuff manually installed on them...assuming the OS doesn't now come with those tools installed by default, or at least optionally.
Ironically, both those things have subsumed the thing they were 'cloning', to the point where they are the default, and everything bends towards them. (It doesn't hurt they were often deliberately designed as the 'middle ground' of different design paradigms.)
But, regardless, both those were designed as replications of the originals. As is ReactOS. Although it's just a clone of one vendor, so has a much higher compatibility hurdle to reach.
The success of ReactOS would depend on whether or not it is actually meaningfully better. If they actually had come out with some product 5 years ago, I can see new companies, when needing to replace Windows XP for some sort of dedicated machine, using ReactOS.
But the problem is they didn't.
Incidentally, Wine, or rather Linux distros that include Wine as a default, have been packaged as a replication for Windows before. There was actually a fairly recent case where some 'pirates', instead of trying to illegally copy Windows, just took one of those distros and slapped in trademark-infringing logos and boot screens to trick people into thinking it was 100% Windows. That's not really the point, the point is that distro was close enough to Windows, and designed in such a way, that doing that was trivial, because it was designed to exactly replicate Windows.
Wine itself, however, is normally positioned as 'Running Windows applications on Linux', not 'Replace Windows'.
Now, supporting Windows drivers on Linux might be something worthwhile to work towards. A good of kernel subsystems already have 'user mode' devices, where a program can fake being a piece of hardware. The rest can probably be added easier.
Taking the ReactOS code that talks to, for example, Windows network card drivers, and hooking it into the network tun/tap system would make Windows network drivers work under Linux. (Yes, yes, ndiswrapper lets you sometimes do this, but networking is just an example.)
And, heck, while we're at it, have the entire ReactOS run under one of those fancy virtual machines Linux just got, but unlike normal virtual machines, the hardware goes both ways...the host OS, Linux, would sometimes need to access things only ReactOS knew how to talk to. Most things would be virtualized in ReactOS, but somethings would be real in ReactOS and virtualized over in Linux, if you see what I'm saying. (You could even virtualize multiple ReactOS instances, one for each driver, and make things more stable.)
This seems to make a lot more sense than building an entire OS, and nothing is stopping someone from duct-taping Wine on top of it and making an actual 'windows clone' OS, that uses Wine to run Windows programs, native Linux to access 95% of the hardware, and ReactOS to access the last 5%.
If you're using telnet to play MUDs, instead of a dedicated client, you're somewhat weird. Or playing it on a computer they probably wouldn't let you play MUDs on if they knew what you were doing. Heck, they now have Java applet clients that work pretty well.
Telnet in Windows can't even handle line-mode, at least not correctly, and hence playing MUDs is a rather annoying experience with it.
I remember back in the good ole days, when newbies would click and follow telnet: links in web browsers, end up connected via telnet or that strange windows modemy program that I forget the name of, and have a rough time of it until someone told them to go and download an actual client that wouldn't scroll text they were typing. (The good ole days being when MUDs actually had new players who'd never played a MUD before. At this point, it's very hard to find a player that hasn't been around at least five years on different games. They might be new to the game, but not MUDding.)
Ironically, right after I posted this, I was talking to my mother, who mentioned that my grandmother wanted some specific show and was there a way for me to download and get it to her, on her DVD player. (My mother has a Linux+XMBC+hellanzb system I set up that automatically downloads TV shows. So she knows about all this downloading stuff, even if she has no idea what's going on behind the scene.)
I was forced to admit I didn't actually know how to make CDs or DVDs that could play in a DVD player from downloaded video. Or, rather, I could figure out how to do it if I knew what actual format I needed to convert to, but I don't.
But, yeah, I know about the people who actually want backup DVDs. That makes a limited amount of sense, and a good deal of sense for people with children. (Especially those people with DVD players in cars. I can just imagine how roughly DVDs in cars get treated by kids.)
I'm not quite sure why people would be using CD-Rs instead of DVD, though.
But there are a lot of people here talking about downloading stuff and putting it on DVD, it seems to me. Maybe I'm crazy and just confusing the two different conversations.
Erm, I said nothing supports cert-less connections.
While I have no idea if Thunderbird in specific can be configured to accept SSL without a cert, I do know most email servers can't beconfigured to operate without one (I certainly couldn't set up dovecot that way.), because most mail clients barf when you do that.
Most clients are entirely happy with self-signed or expired or non-matching certs, but don't want anything to do with you if you try to set up a connection without a cert at all. It's really stupid.
All the cool kids these days have media center PCs, or at least networked STB appliances; but a bottom-of-the-barrel DVD player and a stack of CD-Rs is still fairly compelling for the technophobe or cheapskate.
Hey, I'm a cool kid! That can't be right.
But, yeah, I'm reading this in bemusement. People actually burn downloaded stuff onto a CD-R to watch it? (Presumably actually a CD-RW.) Is this 2002 or something?
Pretty much anyone with technical skills a) bought a dedicated appliance to play stuff off the network, or b) slapped together a PC, threw linux + XBMC on it, maybe hooked in a remote or just a wireless keyboard, or c) ran a cable from the S-video out of their PC, along with a audio splitter or extra sound card, and uses their TV as a second screen, either using XMBC or whatnot, or just telling MPC to launch on the other screen and running to another room.
Even the poorest sap can do (c). Granted, it requires your PC be reasonable close to your TV, unless you can spring for one of those 'wireless video card' they came out with recently. (Also, you have to have a video card with S-Video out, but if you can't afford one of those, you can't afford a DVD player that can play video files on CD.)
Now, I can see why people living with technophobes wouldn't want to do (c)...but that's what XMBC or an appliance is for. Seriously, if you're a geek, even a poor geek, pull together enough dedicated computer to stick Linux+XMBC to hook it to your TV.(1) You don't need a lot for video playback. And if you absolutely cannot afford that, run an S-Video cable from your main computer.
Having to actually put stuff on a physical medium and carry it to your entertainment center...ugh. If you want to watch something, you either have to have already burned to CD, wasting a lot of CD-Rs, or you have run over and burn it at the time. Likewise, you can't start things downloading and come back and have them done, you've still got another step.
1) And someone is about to leap in claiming something else is better than XMBC. Whatever, that's not the point.
And there are plenty of places that MitM would not be relevant.
For example, email and FTP and other clients where the connection is almost certainly set up manually and repeatedly used (vs. web browsing where people may never return) should be fine with unsigned encryption, as all they need to do is store the cert fingerprint and make a fuss if it changes.
But, yes, this is exactly the point I've been making for years. All TCP/IP connections should be opportunistically encrypted, period. Including web pages. There's no reason not to. No, not even CPU. (If the server load is high enough that it matters, by all means, disable it for that server, but it should still be the default.)
Even if it's not the default, make it easy enough to flip on, so that web designers can flip it on for their password and account pages without having to buy a damn cert and get a new IP and other nonsense.
I just had to set up Thunderbird on a new computer, and I noticed, instead of prompting me what sort of email connection (IMAP or POP3) I had, and making me fill out info, it just asked for the server name, and tried the connection itself, prompting me with the ones it found. But the awesome thing was, it actually suggested using an _encrypted_ connection. So, yay, maybe people will actually start using them. (I wonder how many people check their email without even meaning to, via background processes, over open wifi.)
The interesting thing about SSL is that the cert is not actually needed, at all. You can use a SSL connection without a cert on either side, just like you can use one with a cert on both sides.
Sugar is one of those things manufacturers can't actually claim are 'better' than other brands. All sugar is considered to be 100% identical, legally. (Paradoxically, this does allow them to claim to be 'the best', because if everyone is identical, then everyone is tied for 'best'. They're also 'the worst', but somehow that never makes it into their ad.) This makes sense, as it's really all just bought at giant auctions out of grain silos from unknown farmers and stuck into bags.
In fact, I'm not even sure your 'grain size' concept is correct. I suspect what's going on there is that cheaper sugar is in crappier bags, which let in more moisture, which make the sugar turn into 'rock candy' or whatever the technical term for that is. Or perhaps it's already done that in the silos, and they have to 'recrush' it back to smaller size, and the expensive places are better at that. Regardless, I don't think it has anything to do with 'sorting', because you can run sugar through a crusher easier than trying to sort it.
Yes, and the earthquake magically^Wpseudoscientifically^Wscientifically changed the phase state of the copper wiring there, making them a perfect superconductor.
Everyone buy scrap wiring torn out of Haitian buildings! No matter what it costs you.
Now we just need to get the recovery teams in on this, fund the rebuilding of their economy on the backs of morons^Waudiophiles.
Most DACs don't have their own clock. They depend on a signal processor before them to provide the proper clock rate.
Ah, now that I think about it, it makes more sense to say that that way. That's what I was thinking, except I forgot it would be called a DSP.
And it's probably a 75 cent chip that every single S/PDIF input has. In fact, I bet it's part of the spec, and you can't actually label the device as S/PDIF without it.
I can even figure out what's going on: Probably once, back in 1982, some incredibly crappy device that used an entirely different digital data format lazily didn't have a DSP. Thus, from then on, every single audiophile has lived under the theory that digital signals are instantly decoded to audio. Because their word operates on assumptions and rumors and no understanding.
I, OTOH, despite having almost no knowledge about this, or signal processing at all, know the entire damn point of a 'clock' on a signal is to use the signals at a specific time interval, not as soon as possible, and assume there's something in every device that accepts a 'clocked' signal to do exactly that.
On S/PDIF clock and data are merged, so cable quality (which is tied to cable length) affects the recovered clock. Since the clock is tied to data, phase errors due to the cable do not result in a consistent phase error after clock recovery.
Yes, but I'm still not seeing twisting has anything to do with anything. I can see arguments for a shorter cable, but if a moronic audiophile wants the absolute shortest cable, surely companies would sell ones in a billion different lengths, like a 4" cable, a 3.75" cable, a 3.5" cable, etc, instead of one that is 0.5% shorter thanks to slightly less twists. Or people would make their own cables.
Usually I can at least figure out what dumb theory audiophiles are operating off of, but this has me stumped.
The only thing I can guess out of this is that altering the twisting makes the wiring exactly the same length. Whereas in normal twisted pair they are deliberately not exactly the same length, to reduce crosstalk.
Of course, even then, the problem still isn't jitter. It's that one channel is playing a femtosecond out of sync with the other.
But only in imaginary audiophile land where audio equipment (and the human ear) has those tolerances, and doesn't do any sort of processing before sending the combined signals to a DAC...hey, wait a second, that doesn't even make sense. Something has to merge the signals before DACing them, and to do that, it has to rebuild them as a single signal, and...
...bah, this is so stupid I'm just going to give up.
As you degrade an S/PDIF connection, the recovered clock quality suffers until the point where you get data bit errors.
...and, thus, audiophiles use cables slightly more likely to get crosstalk.
I'm not quite following. Are you saying there are DACs that don't...sync their own clock to the stream? Wouldn't that just result in gibberish as the entire thing desyncs?
Oh, wait, you mean they don't have a clock at all, I guess? They instantly decode the signal, and make that tone, and then make a new tone when they get some new bits, as fast as possible, with no regard to actually trying to decode the sounds at correct spacing?
Well, that's just stupid. I can see how that would, in a very slight manner, affect the sound. Although considering we're talking about nanoseconds here, this is of course more audiophile silliness.
But, anyway, the real question is: What the hell are 'audiophiles' doing using such a dumb design? Maybe that $25 DVD player with a digital input is like that, but surely that $5000 receiver has a signal buffer hooked to a clock?
Oh, it does? And they're just morons. Right, I forgot.
Actually, the real question is what the hell this has to do with microscopic differences in cable length anyway. Cable lengths don't alter the clock. Are we assuming multiple signals on different twisted pairs?
Aren't all devices that have RJ-45 (As opposed to the lower-end coax) already the highend stuff? Is there really any device at all that accepts an RJ-45 cable but can't clean up the clock?
It is possible to 'degrade' digital audio with really crappy connections or very bad interference. And when I say 'really', and 'very', I mean really and very.
At which point the entire thing will turn into click and pops and hisses. Horrible, obviously, total failure.
You can't have 'poor quality' digital audio. You either have digital audio, or you have digital gibberish, or at least digital gibberish mixed into digital audio.
I'm having trouble figuring out, exactly, how this would be relevant anyway.
I mean, what it is delayed compared to? I don't understand. Is there some signal path that isn't using this sort of wire? Aren't all the wires in CAT5e twisted the same amount? Where exactly is the 'delay' coming in?
And, even if there is, are they asserting that their wires are within 0.5% tolerance in length in the first place? Really? On a meter of cabling, that's 5mm. Connectors are bigger than that. The inside connectors hooking them into the system are longer than that.
If a SDPIF cable starts losing bits, it will be rather noticeable. It will be full of pops and clicks.
Having a 'bad signal' without it being blatantly obvious is near impossible, and if you get a bad signal, I suggest you move your audio equipment further away from your unshielded nuclear reactor or your kilowatt FM transmission tower or unwrap it from around powerline step-down transformers, or whatever the fuck is causing the problem.
Yeah, diesel dual-powertrain hybrids would seem sorta stupid unless you can keep the diesel engine idling. (I have no idea how dual powertrains actually work.)
However, Volt-style diesel cars would seem ideal. That is, of course, already how they do diesel trains.
It would solve the low-end torque problem of diesel and it would keep the engine from being switched on and off. Battery gets down to 5%, switch the diesel until it's back to 25% or whatever, cut it back off. The idling ability of diesel doesn't really help there, though.
Yes, a car where another passenger adds 20% of the car's weight is going to be more affected by a passenger than one when another passenger adds 5% of the cars weight.
This is not a problem with the first vehicle, and does not make the second vehicle better.
We're not providing poor specifications, we're just letting them do whatever the fuck the way during manufacturing, and then selling it.
It's like when mafia bosses ask someone to 'take care of the problem'. Hey, they didn't say 'kill' anyone.
It's called 'plausibility deniability'. It's not a mistake, it is deliberately closing our eyes while Chinese companies make things however, and then the US company acting all shocked when it contains lead of cadmium or poisonous wasps or whatever is next.
This is because, unlike responsible countries (Which Germany and the UK sound like two.), we don't actually require companies to know anything about products they import beyond what is stated to them. It's sorta the same way we let banks make loans to people based on what those people stated to the banks.
And, just like that situations, where banks told people how to 'lie' to them to meet regulatory guidelines, there are US companies telling Chinese companies what those Chinese companies need to tell the US companies to meet regulations. (You said you use what in the paint? Lalalala, I can't hear you. Hopefully, nothing like lead is going to show up on the official ingredients list, or we won't be able to buy it. Lalala, I'll be going now...)
I'm right there with you, although I actually had somewhat lower expectations for the Democrats. I didn't expect actually bringing anyone to justice. I didn't expect them to be this bad, though.
That said, hey, at least we didn't let McCain start a war with Iran.
Another possible strategy is that you keep working to make the Republicans so idiotic that they're irrelevant, and then encourage the liberal Democrats (Franken, Kucinich et al) to split off from the corporate-owned Democrats (Nelson, Dodd, et al) and form their own party.
Shut up shut up shut up, the Republicans can hear you. They'll learn o...
Um, I mean, that's a crazy idea. The idea that Democrats are running around encouraging the Republican loons, so we can destroy the Republican party, and end up with a right-leaning Democratic party consisting of the DLC-ish Democrats, and another party consisting of the left-leaning Democrats....I mean, I can't even conceive of a way to deny that that would not be blatant lying.
Hey, you teaparty people, keep up the good work. You know, I heard that the Qur'an supports socialized medicine....you guys should make people aware of that. The liberal media certainly won't.
Slashdot Mirror
Someone's going to have to explain to me how the statement 'no games like those two have been made since' makes any sense.
Most multiple character RPGs, like the D&D ones such as Baldur's Gate, Neverwinter Nights, Dragon Age, etc, can be operated in 'turn mode' in combat, where you can have the game automatically pause, and direct the exact movement and combat of each person.
For that matter, X-Com was nowhere near the first one. Turn-based tactical games were some of the first computer combat game, and they're still being made...I point to 'Gunrox'.
And I have no idea why you think TIE fighter is some innovative game genre-wise. It's a very very good game, but it is, at heart, a dogfighting (in space) game. There were some before, and there were plenty after. None really as good, but saying 'They don't make dogfighting games like the best one ever made' is just inane...if anything, TIE Fighter has been over-copied.
Yeah, and despite what the estate may think, that renders the first part public domain.
You can make a Sherlock Holmes story if you make it only using pre-1922 sources. Like, oh, the recent movie, which is a new story set at a rather specific time in the Holmes Canon. (When Watson is about to get married and move out.)
And it's worth pointing out that some stuff just isn't copyrightable. If some post-1922 mentions Sherlock Holmes' mother is named 'Nancy' (It doesn't, but let's pretend.), that doesn't make some new work infringes if it just mentions that. If she was some important character in a post-1922 story, and showed up in a new work with the same traits, yeah, that would infringe, but certain things are regarded as background information about the character, and won't infringe.
You want to see an example of this in real life, watch the stage show Wicked, which is based off the public domain book, and not the copyrighted movie. (Actually, it's based of the book Wicked, which is based ff the public domain book.) Despite this, they're able to get away with recreating some of the sets from the movie, and integrating some of the changes from the movie plot in. For example, how the 'Wicked Witch of the East' dies is how she dies in the movie, not the book, including a total recreation of the iconic scene of a house on top of her and the yellow brick road stretching off into the distance. (With Dorothy having just headed down it.)
There's not some absolute 'You can never mention anything about this public domain character that is from stuff still under copyright' rule. They do still, however, have the silver slippers from the book, which is more a shout-out to the book rather than some sort of legal limitation...they could probably get away with ruby ones.
Incidentally, and people don't know this, but Superman is public domain also. There are public domain newsreel-style shorts from the 1930s and 40s with him in them. I don't really know how much of the Superman universe that gets you, though.
Yes, but X is only half the problem.
What about POSIX?
With graphics, all they have to do is not map graphics calls, which, hilariously, might mean they need to reconvert the graphic calls that Wine converted into X calls back into Windows API, and, you know, actually send them to the Windows drivers. Hopefully they can just not convert them in the first place, writing a stub module to replace the 'X' one in Wine, instead of having to flop them back and forth.
But they're still left with all the non-driver stuff. Like if there's a Windows function to allocate memory and copy a string into it, Wine figures that out by calling a POSIX function. (And then the POSIX layer in the OS makes a libc call, except on Linux and other glibc OSes where the system calls were intelligently written in POSIX convention to start with, and no one has to do anything.)
Well...they ain't got no POSIX underneath. What are they calling? Wine's entire premise is 'mapping Win API into POSIX and X', and while they might be able to easily change that to 'mapping Win API into POSIX and passing graphics on unchanged', they really do need POSIX to have the thing work at all.
Now, and interesting idea might be to have ReactOS come with glibc. Not for programs running in it to use, just for Wine. Is that what's going to happen, or perhaps already does happen?
I have to disagree with you about 1 and 2, which are clone, but with a very important difference:
They were clones of a bunch of very shitty, incompatible, multiple-vendor things.
At the time, Unix kernels hardly supported any hardware at all. They certainly didn't support standard commodity hardware. (No, Minix was a toy, not a real Unix kernel, before anyone mentions that.) They ran on vendor specific hardware.
And same with the utilities included with them. They were, frankly, horrible. In fact, they're still so crappy that you will find GNU stuff manually installed on them...assuming the OS doesn't now come with those tools installed by default, or at least optionally.
Ironically, both those things have subsumed the thing they were 'cloning', to the point where they are the default, and everything bends towards them. (It doesn't hurt they were often deliberately designed as the 'middle ground' of different design paradigms.)
But, regardless, both those were designed as replications of the originals. As is ReactOS. Although it's just a clone of one vendor, so has a much higher compatibility hurdle to reach.
The success of ReactOS would depend on whether or not it is actually meaningfully better. If they actually had come out with some product 5 years ago, I can see new companies, when needing to replace Windows XP for some sort of dedicated machine, using ReactOS.
But the problem is they didn't.
Incidentally, Wine, or rather Linux distros that include Wine as a default, have been packaged as a replication for Windows before. There was actually a fairly recent case where some 'pirates', instead of trying to illegally copy Windows, just took one of those distros and slapped in trademark-infringing logos and boot screens to trick people into thinking it was 100% Windows. That's not really the point, the point is that distro was close enough to Windows, and designed in such a way, that doing that was trivial, because it was designed to exactly replicate Windows.
Wine itself, however, is normally positioned as 'Running Windows applications on Linux', not 'Replace Windows'.
That's the way I feel.
Now, supporting Windows drivers on Linux might be something worthwhile to work towards. A good of kernel subsystems already have 'user mode' devices, where a program can fake being a piece of hardware. The rest can probably be added easier.
Taking the ReactOS code that talks to, for example, Windows network card drivers, and hooking it into the network tun/tap system would make Windows network drivers work under Linux. (Yes, yes, ndiswrapper lets you sometimes do this, but networking is just an example.)
And, heck, while we're at it, have the entire ReactOS run under one of those fancy virtual machines Linux just got, but unlike normal virtual machines, the hardware goes both ways...the host OS, Linux, would sometimes need to access things only ReactOS knew how to talk to. Most things would be virtualized in ReactOS, but somethings would be real in ReactOS and virtualized over in Linux, if you see what I'm saying. (You could even virtualize multiple ReactOS instances, one for each driver, and make things more stable.)
This seems to make a lot more sense than building an entire OS, and nothing is stopping someone from duct-taping Wine on top of it and making an actual 'windows clone' OS, that uses Wine to run Windows programs, native Linux to access 95% of the hardware, and ReactOS to access the last 5%.
If you're using telnet to play MUDs, instead of a dedicated client, you're somewhat weird. Or playing it on a computer they probably wouldn't let you play MUDs on if they knew what you were doing. Heck, they now have Java applet clients that work pretty well.
Telnet in Windows can't even handle line-mode, at least not correctly, and hence playing MUDs is a rather annoying experience with it.
I remember back in the good ole days, when newbies would click and follow telnet: links in web browsers, end up connected via telnet or that strange windows modemy program that I forget the name of, and have a rough time of it until someone told them to go and download an actual client that wouldn't scroll text they were typing. (The good ole days being when MUDs actually had new players who'd never played a MUD before. At this point, it's very hard to find a player that hasn't been around at least five years on different games. They might be new to the game, but not MUDding.)
Erm, not the 'entire' one....there's nothing stopping clients from caching, which is about 80% of the caching done.
Everything else is just ISPs with slow connections trying to make them faster. At some point, we have to stop coddling slow connections.
Of course, there'd be nothing stopping such devices from simply not switching to SSL mode anyway.
Ironically, right after I posted this, I was talking to my mother, who mentioned that my grandmother wanted some specific show and was there a way for me to download and get it to her, on her DVD player. (My mother has a Linux+XMBC+hellanzb system I set up that automatically downloads TV shows. So she knows about all this downloading stuff, even if she has no idea what's going on behind the scene.)
I was forced to admit I didn't actually know how to make CDs or DVDs that could play in a DVD player from downloaded video. Or, rather, I could figure out how to do it if I knew what actual format I needed to convert to, but I don't.
But, yeah, I know about the people who actually want backup DVDs. That makes a limited amount of sense, and a good deal of sense for people with children. (Especially those people with DVD players in cars. I can just imagine how roughly DVDs in cars get treated by kids.)
I'm not quite sure why people would be using CD-Rs instead of DVD, though.
But there are a lot of people here talking about downloading stuff and putting it on DVD, it seems to me. Maybe I'm crazy and just confusing the two different conversations.
Erm, I said nothing supports cert-less connections.
While I have no idea if Thunderbird in specific can be configured to accept SSL without a cert, I do know most email servers can't beconfigured to operate without one (I certainly couldn't set up dovecot that way.), because most mail clients barf when you do that.
Most clients are entirely happy with self-signed or expired or non-matching certs, but don't want anything to do with you if you try to set up a connection without a cert at all. It's really stupid.
All the cool kids these days have media center PCs, or at least networked STB appliances; but a bottom-of-the-barrel DVD player and a stack of CD-Rs is still fairly compelling for the technophobe or cheapskate.
Hey, I'm a cool kid! That can't be right.
But, yeah, I'm reading this in bemusement. People actually burn downloaded stuff onto a CD-R to watch it? (Presumably actually a CD-RW.) Is this 2002 or something?
Pretty much anyone with technical skills a) bought a dedicated appliance to play stuff off the network, or b) slapped together a PC, threw linux + XBMC on it, maybe hooked in a remote or just a wireless keyboard, or c) ran a cable from the S-video out of their PC, along with a audio splitter or extra sound card, and uses their TV as a second screen, either using XMBC or whatnot, or just telling MPC to launch on the other screen and running to another room.
Even the poorest sap can do (c). Granted, it requires your PC be reasonable close to your TV, unless you can spring for one of those 'wireless video card' they came out with recently. (Also, you have to have a video card with S-Video out, but if you can't afford one of those, you can't afford a DVD player that can play video files on CD.)
Now, I can see why people living with technophobes wouldn't want to do (c)...but that's what XMBC or an appliance is for. Seriously, if you're a geek, even a poor geek, pull together enough dedicated computer to stick Linux+XMBC to hook it to your TV.(1) You don't need a lot for video playback. And if you absolutely cannot afford that, run an S-Video cable from your main computer.
Having to actually put stuff on a physical medium and carry it to your entertainment center...ugh. If you want to watch something, you either have to have already burned to CD, wasting a lot of CD-Rs, or you have run over and burn it at the time. Likewise, you can't start things downloading and come back and have them done, you've still got another step.
1) And someone is about to leap in claiming something else is better than XMBC. Whatever, that's not the point.
And there are plenty of places that MitM would not be relevant.
For example, email and FTP and other clients where the connection is almost certainly set up manually and repeatedly used (vs. web browsing where people may never return) should be fine with unsigned encryption, as all they need to do is store the cert fingerprint and make a fuss if it changes.
But, yes, this is exactly the point I've been making for years. All TCP/IP connections should be opportunistically encrypted, period. Including web pages. There's no reason not to. No, not even CPU. (If the server load is high enough that it matters, by all means, disable it for that server, but it should still be the default.)
Even if it's not the default, make it easy enough to flip on, so that web designers can flip it on for their password and account pages without having to buy a damn cert and get a new IP and other nonsense.
I just had to set up Thunderbird on a new computer, and I noticed, instead of prompting me what sort of email connection (IMAP or POP3) I had, and making me fill out info, it just asked for the server name, and tried the connection itself, prompting me with the ones it found. But the awesome thing was, it actually suggested using an _encrypted_ connection. So, yay, maybe people will actually start using them. (I wonder how many people check their email without even meaning to, via background processes, over open wifi.)
The interesting thing about SSL is that the cert is not actually needed, at all. You can use a SSL connection without a cert on either side, just like you can use one with a cert on both sides.
Sadly, absolutely nothing seems to support this.
Sugar is one of those things manufacturers can't actually claim are 'better' than other brands. All sugar is considered to be 100% identical, legally. (Paradoxically, this does allow them to claim to be 'the best', because if everyone is identical, then everyone is tied for 'best'. They're also 'the worst', but somehow that never makes it into their ad.) This makes sense, as it's really all just bought at giant auctions out of grain silos from unknown farmers and stuck into bags.
In fact, I'm not even sure your 'grain size' concept is correct. I suspect what's going on there is that cheaper sugar is in crappier bags, which let in more moisture, which make the sugar turn into 'rock candy' or whatever the technical term for that is. Or perhaps it's already done that in the silos, and they have to 'recrush' it back to smaller size, and the expensive places are better at that. Regardless, I don't think it has anything to do with 'sorting', because you can run sugar through a crusher easier than trying to sort it.
Yes, and the earthquake magically^Wpseudoscientifically^Wscientifically changed the phase state of the copper wiring there, making them a perfect superconductor.
Everyone buy scrap wiring torn out of Haitian buildings! No matter what it costs you.
Now we just need to get the recovery teams in on this, fund the rebuilding of their economy on the backs of morons^Waudiophiles.
Most DACs don't have their own clock. They depend on a signal processor before them to provide the proper clock rate.
Ah, now that I think about it, it makes more sense to say that that way. That's what I was thinking, except I forgot it would be called a DSP.
And it's probably a 75 cent chip that every single S/PDIF input has. In fact, I bet it's part of the spec, and you can't actually label the device as S/PDIF without it.
I can even figure out what's going on: Probably once, back in 1982, some incredibly crappy device that used an entirely different digital data format lazily didn't have a DSP. Thus, from then on, every single audiophile has lived under the theory that digital signals are instantly decoded to audio. Because their word operates on assumptions and rumors and no understanding.
I, OTOH, despite having almost no knowledge about this, or signal processing at all, know the entire damn point of a 'clock' on a signal is to use the signals at a specific time interval, not as soon as possible, and assume there's something in every device that accepts a 'clocked' signal to do exactly that.
On S/PDIF clock and data are merged, so cable quality (which is tied to cable length) affects the recovered clock. Since the clock is tied to data, phase errors due to the cable do not result in a consistent phase error after clock recovery.
Yes, but I'm still not seeing twisting has anything to do with anything. I can see arguments for a shorter cable, but if a moronic audiophile wants the absolute shortest cable, surely companies would sell ones in a billion different lengths, like a 4" cable, a 3.75" cable, a 3.5" cable, etc, instead of one that is 0.5% shorter thanks to slightly less twists. Or people would make their own cables.
Usually I can at least figure out what dumb theory audiophiles are operating off of, but this has me stumped.
The only thing I can guess out of this is that altering the twisting makes the wiring exactly the same length. Whereas in normal twisted pair they are deliberately not exactly the same length, to reduce crosstalk.
Of course, even then, the problem still isn't jitter. It's that one channel is playing a femtosecond out of sync with the other.
But only in imaginary audiophile land where audio equipment (and the human ear) has those tolerances, and doesn't do any sort of processing before sending the combined signals to a DAC...hey, wait a second, that doesn't even make sense. Something has to merge the signals before DACing them, and to do that, it has to rebuild them as a single signal, and...
As you degrade an S/PDIF connection, the recovered clock quality suffers until the point where you get data bit errors.
Exactly the behavior I'd expect from them.
I'm not quite following. Are you saying there are DACs that don't...sync their own clock to the stream? Wouldn't that just result in gibberish as the entire thing desyncs?
Oh, wait, you mean they don't have a clock at all, I guess? They instantly decode the signal, and make that tone, and then make a new tone when they get some new bits, as fast as possible, with no regard to actually trying to decode the sounds at correct spacing?
Well, that's just stupid. I can see how that would, in a very slight manner, affect the sound. Although considering we're talking about nanoseconds here, this is of course more audiophile silliness.
But, anyway, the real question is: What the hell are 'audiophiles' doing using such a dumb design? Maybe that $25 DVD player with a digital input is like that, but surely that $5000 receiver has a signal buffer hooked to a clock?
Oh, it does? And they're just morons. Right, I forgot.
Actually, the real question is what the hell this has to do with microscopic differences in cable length anyway. Cable lengths don't alter the clock. Are we assuming multiple signals on different twisted pairs?
Aren't all devices that have RJ-45 (As opposed to the lower-end coax) already the highend stuff? Is there really any device at all that accepts an RJ-45 cable but can't clean up the clock?
Yeah, that's what I keep saying.
It is possible to 'degrade' digital audio with really crappy connections or very bad interference. And when I say 'really', and 'very', I mean really and very.
At which point the entire thing will turn into click and pops and hisses. Horrible, obviously, total failure.
You can't have 'poor quality' digital audio. You either have digital audio, or you have digital gibberish, or at least digital gibberish mixed into digital audio.
I'm having trouble figuring out, exactly, how this would be relevant anyway.
I mean, what it is delayed compared to? I don't understand. Is there some signal path that isn't using this sort of wire? Aren't all the wires in CAT5e twisted the same amount? Where exactly is the 'delay' coming in?
And, even if there is, are they asserting that their wires are within 0.5% tolerance in length in the first place? Really? On a meter of cabling, that's 5mm. Connectors are bigger than that. The inside connectors hooking them into the system are longer than that.
If a SDPIF cable starts losing bits, it will be rather noticeable. It will be full of pops and clicks.
Having a 'bad signal' without it being blatantly obvious is near impossible, and if you get a bad signal, I suggest you move your audio equipment further away from your unshielded nuclear reactor or your kilowatt FM transmission tower or unwrap it from around powerline step-down transformers, or whatever the fuck is causing the problem.
It's sorta like the lottery. It's a stupid tax.
Yeah, diesel dual-powertrain hybrids would seem sorta stupid unless you can keep the diesel engine idling. (I have no idea how dual powertrains actually work.)
However, Volt-style diesel cars would seem ideal. That is, of course, already how they do diesel trains.
It would solve the low-end torque problem of diesel and it would keep the engine from being switched on and off. Battery gets down to 5%, switch the diesel until it's back to 25% or whatever, cut it back off. The idling ability of diesel doesn't really help there, though.
They're talking about a hybrid system LIKE ON THE VOLT, the subject of this article.
Geez.
Yes, a car where another passenger adds 20% of the car's weight is going to be more affected by a passenger than one when another passenger adds 5% of the cars weight.
This is not a problem with the first vehicle, and does not make the second vehicle better.
It's not 'sloppy' if you just don't care.
We're not providing poor specifications, we're just letting them do whatever the fuck the way during manufacturing, and then selling it.
It's like when mafia bosses ask someone to 'take care of the problem'. Hey, they didn't say 'kill' anyone.
It's called 'plausibility deniability'. It's not a mistake, it is deliberately closing our eyes while Chinese companies make things however, and then the US company acting all shocked when it contains lead of cadmium or poisonous wasps or whatever is next.
This is because, unlike responsible countries (Which Germany and the UK sound like two.), we don't actually require companies to know anything about products they import beyond what is stated to them. It's sorta the same way we let banks make loans to people based on what those people stated to the banks.
And, just like that situations, where banks told people how to 'lie' to them to meet regulatory guidelines, there are US companies telling Chinese companies what those Chinese companies need to tell the US companies to meet regulations. (You said you use what in the paint? Lalalala, I can't hear you. Hopefully, nothing like lead is going to show up on the official ingredients list, or we won't be able to buy it. Lalala, I'll be going now...)
I'm right there with you, although I actually had somewhat lower expectations for the Democrats. I didn't expect actually bringing anyone to justice. I didn't expect them to be this bad, though.
That said, hey, at least we didn't let McCain start a war with Iran.
Another possible strategy is that you keep working to make the Republicans so idiotic that they're irrelevant, and then encourage the liberal Democrats (Franken, Kucinich et al) to split off from the corporate-owned Democrats (Nelson, Dodd, et al) and form their own party.
Shut up shut up shut up, the Republicans can hear you. They'll learn o...
Um, I mean, that's a crazy idea. The idea that Democrats are running around encouraging the Republican loons, so we can destroy the Republican party, and end up with a right-leaning Democratic party consisting of the DLC-ish Democrats, and another party consisting of the left-leaning Democrats....I mean, I can't even conceive of a way to deny that that would not be blatant lying.
Hey, you teaparty people, keep up the good work. You know, I heard that the Qur'an supports socialized medicine....you guys should make people aware of that. The liberal media certainly won't.