File system. Just think about assembly names specified inconsistently.
On the other hand, I think that the number of Linux applications relying on a case-sensitive file system and a "/" path separator (which, of course, is accepted in most places in Windows) is also quite high, so this is more the general hassles of porting for an application where it wasn't intended. Hey, you can even put in file system assumptions in a Java-only Windows application.
It's quite a different thing to copy a bit and to remove waterprinting data with an acceptable loss in quality. On the other hand, I would be truely impressed if they succeeded in creating a technology which made reading the print trivial even with a transcoded and compressed copy down to a level where the compression would make the copy "uninteresting". It could be relatively easy to make a perfect rip 100 % identifiable and force all copies to lose some quality in covering up the waterprint. And, no, even by knowing the algorithm and the waterprint data that doesn't mean you can restore back the original picture/sound/date.
Encryption of the transfers will, of course, only make this useful when the source of some material is questioned after a warrant.
Nope. You generally seed the system with a self-replicating program first. If you start with something like a huge Conway's game of life board, with random dots appearing and disappearing, it will take very long until you get self-replicating structures.
To make any useful experiments with digital evolution, we will seed them with an environment where they are able to reproduce themselves from the beginning and where that's not a very hard thing to do -- and let the randomness start from there.
If you say the same thing is relevant for our physical laws, you gotta explain the ten billion years between "dawn of time" and "some life on Earth". Simulations like this may provide some additional insights into how systems with mutations and natural selection behave. I don't think it will provide more insight into how they first arise, unless a much more demanding and general world-simulation is created -- with natural laws much more similar to our own to have any relevance in the matter. The wait before any results turned up would, probably, be very boring and could last for (human) generations. The other insight, of course, is that sentient minds can start the cycle of natural selection, but that's a trivial result that doesn't say a iota about our condition.
The point is the OEM market (as always). This might get some OEMs to bundle another media player, but they'll probably ask Real or whatever to pay them to do so.
Fine. By this definition, you rule out scientific study of any effects caused by humans.
Your parent is correct, the root of science is observation, not hypothesis or theory. Before Kepler formulated his laws (out of which some were completely non-sensical bogus, as far as we know now, about Pythagoreical bodies inside one another), he had access, among other things, to Brahe's vast observational data about planetary positions. Brahe wasn't a Copernican (IIRC), so the data were collected with a completely different intent, but from those data, Kepler could infer elliptical orbits and the observations of constant angular speed.
Of course, normally you have some faint hunch about what you are trying to measure when you collect data, and that's part of the problem. That hunch or idea is not science, even though it may be based on your scientific knowledge, for example common theoretical explanations of what you would expect happening. The real science starts when you have conducted experiments, formulated some model explaining them and then can use that model to predict the results of other data sets, preferably in future experiments, but maybe from other sources that weren't accessible to you when creating the model.
If you know exactly what you'll find, it's just a boring verification of existing science. If you start out with a new theory, based on nothing, and try to prove it, that's not science. If you start with a question: "Do these two variables correlate?", that's good. That's stuff that you are able to verify. If you find a correlation, you can try to explain what it is.
People are good at remembering linguistic data. There are many many words that can be put together in sentences that make sense, but still would be very hard to create a dictionary attack against.
I type the equal of thousands of sentences each day.
More importantly, what in Enterprise made it more PC than previos Star Trek series? If I would give a single complaint it was the lack of PC, without adding anything in the process of removing the origins of the franchise.
I like Star Wars because it has excellent acting and dealt with good versus evil. Star Wars is essentially a medieval tale (of knights and a princess) shrouded in sci-fi props: lasers, spaceships, etc.
And that is why we have to be really careful about Trek. I do NOT want it to deteriorate into a we-are-good-because-we-are-good story. ST is about people with ideals. SW is more about, well, people.
In addition to the acting, what I couldn't find in Enterprise were those ideals. Sure, Archer talks about them sometimes, but I simply don't get that impression. Even Voyager could give me some of that. In fact, I think parts of DS9 got too much of "epic tale of good against evil" sometimes, while Voyager at its worst just got boring. I think I, for one, can prefer boring.
Many good points, but I simply can't agree on this one: -MS programs inherently run 5x faster than any competitors programs (something to do with APIs)
What kind of APIs do you really think they use that give such a great speed boost and still are unavailable to everybody else? You know, it's not that hard to track down what the software actually does with debuggers and monitoring tools. Yes, some Microsoft products use some undocumented calls, but they are mainly insignificant. On the other hand, many true performance hogs on Windows systems do absolutely outrageous things, like reading a multi-MB file in few-byte chunks (bad if you do it often), polling the registry constantly even during idle operation, writing to the registry constantly during idle operation, Plain Stupid(TM) painting code doing things like re-enumerating all fonts, rereading all settings and then redrawing the whole window to a off-screen buffer, to then transfer the whole bitmap to screen, preferably with a different color depth so it's not a simple bit transfer operation.
Ok, I've generally not seen all of these in the same application, but if you see one, you're likely to meet some of the other ones. Some of them are in MS applications, most are not. Outlook Express is generally an example of how you should not write a well-performing Windows application, while ICQ, for example, is far, far worse.
I've yet to see that wonderous user-mode behavior that I've no idea how they could implement and which simply must be filled with "illegal" hooks. I take it this is more about of user applications and not stuff like SQL Server and Exchange, but on the other hand I've not seen Oracle crying that high over this, although Windows is not a main platform for their offerings.
But it never happens that different people want to do the same thing, if "same" is still the same if one family member wants to watch his disk recorded favorite show, while another wants to watch hers? And they're on the same disk?
That's why several interconnected devices of more or less similar types (some will have large screens, some will have small ones, some would have none at all, some systems will be portable), possibly based on different "use niches" that are already existing (from this point of view, a walkman and an Ipod are basically equal), would actually add something. IMHO, to just connect all kinds of stuff together without at least some degree of central storage and coordination is a quite hard engineering problem. It's also easier for non-geeky users to know that all their "stuff" is on one device, so they for example know what will break if they take something with them on a holiday or throw it out the window.
So, tell me, why do you prefer separate devices that you can't interface to each other, can't customize over just as many real possible simultaneous users, with higher flexibility? The number of devices would be lower, no need for a DVD and a VCR to each display/TV if you have many, as they all serve the same purpose and the data would probably be centrally stored anyway.
Agreed/me too. OTOH, this tells us that the original poster doesn't have to look far for people interested in "convergence".
Dual-core would naturally make it easier to get real-time performance/harder for sloppy coding to show up as hickups in playing, for example. Except for that, I don't think much is needed on the PC side. What's needed is cheaper/smarter peripherals that handle 1394/USB2 and 802.11*, preferably with open interfaces.
I have four devices capable of playing music and video in one form or another that I use regularly. Main PC, laptop, palm-size device and phone. All of them are capable of running code I've written myself, with the exception that the Sony phone could preferably support more access through its Java API.
If I can't code for it, it has to be really neat or at least accept data in a somewhat manageable form from a PC.
There are what's called Volume Shadows in Windows XP and later (naturally more accessible in the server version). It's basically what you describe. You can revert a disk to a previous state, or mount it and copy specific files back.
Naturally, this feature is not unique in any way to the NTFS implementation of Windows, but as we're discussing MS problems here, that's the most directly relevant thing. Any journaling FS could/should be able to do this. And, still, remember that the only safe thing if your system really has been compromised is a physically separated backup.
There's also (even in...shrug... Windows Me) System Restore, which does provide a degree of restoration of Registry and files to a previous point in time.
The problems here are things like for how long you should go on keeping old versions, how do you know when the malware change was done, how sure can you be that the malware in question isn't capable of injecting itself into the previous versions, and so on.
I really disagree here. Clever code may be one thing, but readable code should need very few comments except for the few really tricky parts. A few lines above each function desribing them (perharps Javadoc style) is good, but if you need to explain what you're doing for every line, your code is bad. Keeping comments describing what your bad code does to make it readable is a worse option than readable code -- twice the amount of data and you need to keep them synchronized. (What if the bad code really doesn't do what the good comment tells you that it does? A clear no-no.)
A comment containing some profanity may not be the best way to do it, but I can understand the sentiment. A comment could be in place exactly to alleviate a "WTF" sensation for the prospective reader, it could seem that something strange is going on in the code, and we've written a description for why it is that way, maybe even after having debugged it ourselves.
Good code with good variable naming in a good language needs little commenting. As I said, method header comments is another cup of tea, because those may more center around design decisions and the bigger picture, which might be harder to get just by reading the individual pieces of code, no matter how well-commented each piece is.
RTFB (blog). This is one developer thinking that he could get approval for a release of the source for a component, similar to how they've done for ages with their C library and MFC. He discusses the possibility of stripping all comments out, but also the possibility of editing the comments in a few crucial by hand so they are politically correct enough, employing the community of already close to MS MVP drones to edit all files, or edit everything in-house and put out a somewhat clean and commented source.
There is actually a somewhat Perl-compatible Regex class inside the.NET Framework. They don't have to leave the comfy C# sandbox to get it done.
BTW, the Visual C++ IDE is nice for Windows development, but I can manage without for sure. Being left with only vi and no emacs, on the other hand, that's cruelty to me.
Then, you send the signal to turn it on, two lighthours away, and wait for the ping to get back.
Hey, even when it's a remote server without the more fancy types of monitoring, you can only guess by realizing it doesn't answer to even the simplest calls that it might be turned off. On the other hand, the cable might have been disconnected, the computer may have decided to move its directional antenna out of focus on purpose (hal.dll, where are you?) and so on...
OTOH, marketshare and "mindshare" is declining, even though we shouldn't forget that while Linux is gaining from both Windows and mainframe/big-name UNIX, the general trend towards (relatively) cheap x86 is still a good thing for both those platforms. When the total market size stops expanding or enters a much slower expansion, MS will be in for trouble.
Even the travel Earth - Proxima Centuari would take a few millenia with this star. If we had any serious intra-gallactic travel, hitchhinking on a star like this at its speed would be purely boring.
Well, he's also talking about the K9 delays. I think that the failure of the Prescott in some ways show what problems both leading x86 vendors are fighting against. Isn't SOI, BTW, more of an IBM deal that AMD cross-licensed?
And, yeah, the only Intel CPU I currently like is the Pentium M, and I hope you can forgive that. If I would currently buy a new main machine, it would probably be AMD, but I'm holding out for dual-core releases from them. I like the effects that both "real" SMP and hyper-threading has on general responsiveness and a dual-core AMD64 chip would fit very nicely.
Read my own clarification response above yours, I intended to write that x86 is cramped by its register count (and the further restrictions on what to use when), but that 256 is very, very much.
The Itanium has a huge file with, IIRC, even more registers in total. They are not inter-changeable, though, but the (almost) only point in that would be to keep the total number of registers down, while being flexible for most types of code. As I think that it's generally actually easier to make them separate for different execution units, that's not very interesting. Also, note that the Itanium currently has a 2-cycle (again, IIRC) register access time! They tried to be visionary, adding a huge register set, in addition to some parallelism encoding and other things I mentioned in the parent, but they traded (what seems to be) far too much to get it.
A huge (defined as MMIX-like, not AMD64-like)register file might be great, but you need selective register pushing to stack to get away with it, unless you or the compiler are performing very aggressive inlining. What's easier, if you're doing assembler -- calling a function and put a local on the stack or writing a huge fricking implementation of your main algorithm, taking great care to use all different registers in each function inlining?
I don't agree that more registers would actually do that much good.
Clarification: It's easy to see that you move in and out of registers and force the CPU to do register renaming to get good parallelism in x86. I fail to see the benefits from a real performance standpoint when you reach above let's say 32 of each kind, and I think that the 16 available in AMD64 should be fine for most tasks. The problem in x86 is that they are eight and even those have locked meanings to some degree.
Ok, classic x86 is cramped and the CPU does a lot of register renaming to get around it. I don't agree that more registers would actually do that much good.
What kind of algorithm are you imagining would benefit from 256 fields of non-vectorized data?
Of course, those registers could be used in larger things for everything that's worthy of a local variable, but as soon as you run into a stack operation you'll either only want to push a subset of the registers to the stack, or face a harder blow of memory access times by making each function call a 2048 byte write to memory.
Explicit encoding of parallelism, hints to branch prediction, and similar stuff, seems far more appropriate.
Again, few single functions in an imperative language have 256 separate variables, without involving arrays of data. Unless the register file is addressable by index from another register (basically turning it into a very small addressed memory, which is whta you try to avoid with registers), you have little use for 256 of them. Take for example a trivial string iteration algorithm, most of those registers would be completely useless. The same holds true for common graph algorithms.
Stop it, please, just stop it. Win32 is not dead. GDI is somewhat dead as the main interface for doing GUI stuff in Windows in the future, but the basis of GDI has been around all since Windows 1.0 (and a painting program before that). They keep it compatible, as an emulation in a texture that's then painted, unless that's changed. They are not breaking everything. The transition from MacOS 9 to MacOS X was more significant, as the kernel and non-GUI APIs are mainly unaltered here.
Slashdot Mirror
On the other hand, I think that the number of Linux applications relying on a case-sensitive file system and a "/" path separator (which, of course, is accepted in most places in Windows) is also quite high, so this is more the general hassles of porting for an application where it wasn't intended. Hey, you can even put in file system assumptions in a Java-only Windows application.
Encryption of the transfers will, of course, only make this useful when the source of some material is questioned after a warrant.
To make any useful experiments with digital evolution, we will seed them with an environment where they are able to reproduce themselves from the beginning and where that's not a very hard thing to do -- and let the randomness start from there.
If you say the same thing is relevant for our physical laws, you gotta explain the ten billion years between "dawn of time" and "some life on Earth". Simulations like this may provide some additional insights into how systems with mutations and natural selection behave. I don't think it will provide more insight into how they first arise, unless a much more demanding and general world-simulation is created -- with natural laws much more similar to our own to have any relevance in the matter. The wait before any results turned up would, probably, be very boring and could last for (human) generations. The other insight, of course, is that sentient minds can start the cycle of natural selection, but that's a trivial result that doesn't say a iota about our condition.
The point is the OEM market (as always). This might get some OEMs to bundle another media player, but they'll probably ask Real or whatever to pay them to do so.
Your parent is correct, the root of science is observation, not hypothesis or theory. Before Kepler formulated his laws (out of which some were completely non-sensical bogus, as far as we know now, about Pythagoreical bodies inside one another), he had access, among other things, to Brahe's vast observational data about planetary positions. Brahe wasn't a Copernican (IIRC), so the data were collected with a completely different intent, but from those data, Kepler could infer elliptical orbits and the observations of constant angular speed.
Of course, normally you have some faint hunch about what you are trying to measure when you collect data, and that's part of the problem. That hunch or idea is not science, even though it may be based on your scientific knowledge, for example common theoretical explanations of what you would expect happening. The real science starts when you have conducted experiments, formulated some model explaining them and then can use that model to predict the results of other data sets, preferably in future experiments, but maybe from other sources that weren't accessible to you when creating the model.
If you know exactly what you'll find, it's just a boring verification of existing science. If you start out with a new theory, based on nothing, and try to prove it, that's not science. If you start with a question: "Do these two variables correlate?", that's good. That's stuff that you are able to verify. If you find a correlation, you can try to explain what it is.
I type the equal of thousands of sentences each day.
More importantly, what in Enterprise made it more PC than previos Star Trek series? If I would give a single complaint it was the lack of PC, without adding anything in the process of removing the origins of the franchise.
In addition to the acting, what I couldn't find in Enterprise were those ideals. Sure, Archer talks about them sometimes, but I simply don't get that impression. Even Voyager could give me some of that. In fact, I think parts of DS9 got too much of "epic tale of good against evil" sometimes, while Voyager at its worst just got boring. I think I, for one, can prefer boring.
Please! Stop it! A self-destruct device is anachronistic! It can't possibly happen before Kirk...did...it...in...Star...Trek...III!
What kind of APIs do you really think they use that give such a great speed boost and still are unavailable to everybody else? You know, it's not that hard to track down what the software actually does with debuggers and monitoring tools. Yes, some Microsoft products use some undocumented calls, but they are mainly insignificant. On the other hand, many true performance hogs on Windows systems do absolutely outrageous things, like reading a multi-MB file in few-byte chunks (bad if you do it often), polling the registry constantly even during idle operation, writing to the registry constantly during idle operation, Plain Stupid(TM) painting code doing things like re-enumerating all fonts, rereading all settings and then redrawing the whole window to a off-screen buffer, to then transfer the whole bitmap to screen, preferably with a different color depth so it's not a simple bit transfer operation.
Ok, I've generally not seen all of these in the same application, but if you see one, you're likely to meet some of the other ones. Some of them are in MS applications, most are not. Outlook Express is generally an example of how you should not write a well-performing Windows application, while ICQ, for example, is far, far worse.
I've yet to see that wonderous user-mode behavior that I've no idea how they could implement and which simply must be filled with "illegal" hooks. I take it this is more about of user applications and not stuff like SQL Server and Exchange, but on the other hand I've not seen Oracle crying that high over this, although Windows is not a main platform for their offerings.
That's why several interconnected devices of more or less similar types (some will have large screens, some will have small ones, some would have none at all, some systems will be portable), possibly based on different "use niches" that are already existing (from this point of view, a walkman and an Ipod are basically equal), would actually add something. IMHO, to just connect all kinds of stuff together without at least some degree of central storage and coordination is a quite hard engineering problem. It's also easier for non-geeky users to know that all their "stuff" is on one device, so they for example know what will break if they take something with them on a holiday or throw it out the window.
So, tell me, why do you prefer separate devices that you can't interface to each other, can't customize over just as many real possible simultaneous users, with higher flexibility? The number of devices would be lower, no need for a DVD and a VCR to each display/TV if you have many, as they all serve the same purpose and the data would probably be centrally stored anyway.
Dual-core would naturally make it easier to get real-time performance/harder for sloppy coding to show up as hickups in playing, for example. Except for that, I don't think much is needed on the PC side. What's needed is cheaper/smarter peripherals that handle 1394/USB2 and 802.11*, preferably with open interfaces.
I have four devices capable of playing music and video in one form or another that I use regularly. Main PC, laptop, palm-size device and phone. All of them are capable of running code I've written myself, with the exception that the Sony phone could preferably support more access through its Java API.
If I can't code for it, it has to be really neat or at least accept data in a somewhat manageable form from a PC.
Naturally, this feature is not unique in any way to the NTFS implementation of Windows, but as we're discussing MS problems here, that's the most directly relevant thing. Any journaling FS could/should be able to do this. And, still, remember that the only safe thing if your system really has been compromised is a physically separated backup.
There's also (even in...shrug... Windows Me) System Restore, which does provide a degree of restoration of Registry and files to a previous point in time.
The problems here are things like for how long you should go on keeping old versions, how do you know when the malware change was done, how sure can you be that the malware in question isn't capable of injecting itself into the previous versions, and so on.
A comment containing some profanity may not be the best way to do it, but I can understand the sentiment. A comment could be in place exactly to alleviate a "WTF" sensation for the prospective reader, it could seem that something strange is going on in the code, and we've written a description for why it is that way, maybe even after having debugged it ourselves.
Good code with good variable naming in a good language needs little commenting. As I said, method header comments is another cup of tea, because those may more center around design decisions and the bigger picture, which might be harder to get just by reading the individual pieces of code, no matter how well-commented each piece is.
RTFB (blog). This is one developer thinking that he could get approval for a release of the source for a component, similar to how they've done for ages with their C library and MFC. He discusses the possibility of stripping all comments out, but also the possibility of editing the comments in a few crucial by hand so they are politically correct enough, employing the community of already close to MS MVP drones to edit all files, or edit everything in-house and put out a somewhat clean and commented source.
BTW, the Visual C++ IDE is nice for Windows development, but I can manage without for sure. Being left with only vi and no emacs, on the other hand, that's cruelty to me.
Hey, even when it's a remote server without the more fancy types of monitoring, you can only guess by realizing it doesn't answer to even the simplest calls that it might be turned off. On the other hand, the cable might have been disconnected, the computer may have decided to move its directional antenna out of focus on purpose (hal.dll, where are you?) and so on...
OTOH, marketshare and "mindshare" is declining, even though we shouldn't forget that while Linux is gaining from both Windows and mainframe/big-name UNIX, the general trend towards (relatively) cheap x86 is still a good thing for both those platforms. When the total market size stops expanding or enters a much slower expansion, MS will be in for trouble.
Even the travel Earth - Proxima Centuari would take a few millenia with this star. If we had any serious intra-gallactic travel, hitchhinking on a star like this at its speed would be purely boring.
And, yeah, the only Intel CPU I currently like is the Pentium M, and I hope you can forgive that. If I would currently buy a new main machine, it would probably be AMD, but I'm holding out for dual-core releases from them. I like the effects that both "real" SMP and hyper-threading has on general responsiveness and a dual-core AMD64 chip would fit very nicely.
The Itanium has a huge file with, IIRC, even more registers in total. They are not inter-changeable, though, but the (almost) only point in that would be to keep the total number of registers down, while being flexible for most types of code. As I think that it's generally actually easier to make them separate for different execution units, that's not very interesting. Also, note that the Itanium currently has a 2-cycle (again, IIRC) register access time! They tried to be visionary, adding a huge register set, in addition to some parallelism encoding and other things I mentioned in the parent, but they traded (what seems to be) far too much to get it.
A huge (defined as MMIX-like, not AMD64-like)register file might be great, but you need selective register pushing to stack to get away with it, unless you or the compiler are performing very aggressive inlining. What's easier, if you're doing assembler -- calling a function and put a local on the stack or writing a huge fricking implementation of your main algorithm, taking great care to use all different registers in each function inlining?
What kind of algorithm are you imagining would benefit from 256 fields of non-vectorized data?
Of course, those registers could be used in larger things for everything that's worthy of a local variable, but as soon as you run into a stack operation you'll either only want to push a subset of the registers to the stack, or face a harder blow of memory access times by making each function call a 2048 byte write to memory.
Explicit encoding of parallelism, hints to branch prediction, and similar stuff, seems far more appropriate.
Again, few single functions in an imperative language have 256 separate variables, without involving arrays of data. Unless the register file is addressable by index from another register (basically turning it into a very small addressed memory, which is whta you try to avoid with registers), you have little use for 256 of them. Take for example a trivial string iteration algorithm, most of those registers would be completely useless. The same holds true for common graph algorithms.
Stop it, please, just stop it. Win32 is not dead. GDI is somewhat dead as the main interface for doing GUI stuff in Windows in the future, but the basis of GDI has been around all since Windows 1.0 (and a painting program before that). They keep it compatible, as an emulation in a texture that's then painted, unless that's changed. They are not breaking everything. The transition from MacOS 9 to MacOS X was more significant, as the kernel and non-GUI APIs are mainly unaltered here.