You do realize, that some memory resident program that interprets drivers on behalf of the user.. is like a JVM (or Parrot) which interprets specially formated byte code programs?
Well, if you are saying that the driver-wrapper actually reads the x86 binary, and interprets that, then you really have a marvel of engineering.
But what makes sense, and would probably be possible to do is to just create a wrapper. The driver expects certain "hooks" to be able to talk to Windows. The wrapper provides them, and also handles communication with the linux kernel. Since this is so lowlever, it would probably not even require a single code of wine. But at the very minimum, it would require some assembly to translate between the varying calling conventions. If you are unlucky (most likely), it will also require keeping some state, as the low-level interface for NIC drivers is probably quite different in windows and linux.
Right, because those of use using Open are doing so out of total performance. Lets do a comparison of the security of these systems and see who wins that one.
Ok, let's start with resilience. Quoting from fork benchmark: "OpenBSD does not scale at all, and even panics under high load."
High end tapes have since eclipsed MO in write performance, but are still more fragile and certainly not random access.
Uhh, high-end tapes have always had faster write-speeds than hard-disks. If all you want to do is write data fast, use tapes, or maybe a SAN or something like that. But then again, it's possible we have different opinions about what constitutes "high-end".
Hey, there's a reason that there is still a market for PDP-11 emulator boards! Afterall, when the PDP-11 in your nuclear powerplant dies, you don't want to have to rewrite the software.
Well maybe. If your nuclear power plant depends on it, you are hopefully extremely paranoid about replacements. A failure may result in more than just a lost time incident (which by itself would be pretty bad), it could actually be catastrophic. You would have to do extensive testing of the emulator and the new hardware before accepting substitutes for the real thing. It might end up being more work than writing a new version and testing it.
A more likely scenario is to use it for less mission-critical stuff, but still stuff that you need available most of the time, but doesn't seem important enough to warrant a huge investment. I.e. replacement for ancient data loggers, etc...
On the other hand, I'm pretty sure most of them are used by hobbyists...
If somebody decided to put an Alpha machine into an important application, they would definitely need an emulator for it.
Excuse me! What planet are you from? If you can point to just one example of a any company or institution that refuses to use any computer before it can be emulated on another, I will happily go kill myself. Even long after an ISA dies, you can usually get spare parts from other systems taken out of service. Or you could buy all spare parts you needed in advance. As long as you are dealing with computers, nobody can plan beyond a 20 year lifespan.
And remember, it's not too hard to emulate a 5-year-old machine at realtime speeds.
Yes it is. There's a lot of quirky details with emulating real hardware. Computers grow more complicated every year, and it's not just the CPU we are interested in emulating. Writing an emulator for, say a 5 year old x86 is a major undertaking (don't say that writing bochs was "not too hard").
And if you want to make sure it runs your mission-critical tasks properly, you'd better make damn sure every detail is perfect. And that includes emulation or interfaces for any proprietar or otherwise unavailable or "weird" hardware you might have added.
Huh? Because the Alpha was all about speed, and now you are touting VMs? Do you think things tend to run faster on VMs?
If your vendor dies, you can just move applications to a new platform and the users will not notice a difference.
Well, the VM is a platform too. If the vendor dies, you either have to find another vendor, or start porting. There were no greater risc involved in choosing Alpha. After being slaughtered in '97, it's still available, and will be for yet another generation. And even after it's completely dead, you can still find used ones. If you absolutely need an instruction set architecture that lives forever, you know where to find it.
This is one amazing chip and it was at one time lightyears ahead of anything Intel put out. I honestly believe that HP is making a mistake here by ditching this chip. Sure R&D costs of chip design and production are enormous but HP is hitching their wagon to the Itanic?
The Alpha was formerly Compaq and even before that a Digital invention. HP has their PA-RISC architecture, of which Itanium was planned from the start to replace (one of the design requirements for Itanium was that a software translator for binary PA-RISC code was made possible).
Furthermore, as far as I know, the Alpha is still produced by Intel, not by HP/Compaq/Digital, as Compaq sold their alpha plants, personell and all associated IP to Intel (and thus avoided a lawsuit, as well as ensuring the Alphas future for a few years). There were also plans for a Itanium version of Tru64 (formerly Digital Unix), but I am unsure as to whether it was ever commercialized.
All in all. It seems like a pretty sound business decision to me. This is what "they" have planned all along, for many years, whether "they" are Digital, Compaq, HP, or Intel.
In particular, I remember the instruction set being a breath of fresh air, logical and simple, and that spoke to me of a good basic design, one that would age well.
Yeah, I remember the same thing. Unfortunately, it didn't age well. Don't know if that should tell us something... Maybe that marketshare is more important than technical benefits? May all future good designs rest in peace!
Yet these companies/individuals know that their marketing hardly ever works (what's the reply rate of spam? Something like.0001%?). So why do they keep coming to work? Are they idiots?
If it's the same spammers who go on and on doing it, I think it's safe to guess they have found a formula that works, and are getting rich by doing it. A 0.0001% return rate, means that they need to earn 1000000 times the cost of sending one email per sale. Considering that sending email is basically free, and that 0*1000000 is still 0, this means that even low success rates can give rise to high profits.
Actually you will hit Amdall law's very soon. [snip]
For the current generation of typical computers, 50, 100, or 300 processors is still a lot more than what is common. Mostly, it is 1. Meaning we still have quite a lot of speedup to gain before Amdahls law makes it all worthless.
Systems with more than 1 processor today are usually servers or running other kinds of easily paralellizable processes.
The main reason most of todays systems avoid having too many processors is probably not Amdahls law. My guess would be a combination of history, market demand (will it run my software (and better?)), and the obvious problem of memory bandwidth which makes multiple processors cost more than just the processor cores, if you want to keep them busy.
In otherwords... cutting edge is going to be expensive forever?
Uh, what would you expect. When "cutting edge" eventually gets affordable, don't you suspect that someone would offer something a little bit faster that costs just a few hundred times more?
Considered the length of the grant-cycle I usually have outdated technology... I suppose if this sort of technology becomes the leader, I would still have to have the resources of a large research university to get anything done. At least the way it is now, my home machine is faster then the one at work!
Then rent some computer time from somebody that has bought a decent machine. It's still possible to do that, right?:-)
now, none has find a way to transform serial code to parallel. There's a simple Touring machine that converts parallel graphs to serial, no one has ever came up with a Touring machine that takes serial code and makes it a "perfect" (every posible paralelism degree) parallel one. Thas the saint-grial that seems unrecheable... up to then, only some apps can scale with those CMT processors.
While obviously true, it means very little in practice. Mostly, tasks that take a lot of time are easily converted to paralell subtasks by a human. And we certainly don't need "perfect" paralellism. For some tasks, it's sufficient with "faster", and for all tasks it's sufficient with "faster at same or lower cost".
AIFF seems to be the high-resolution ripping option
Yes, I have to agree with you Michael. AIFF is so much better than WAV. After all, it's less known, and is mentioned in stereophile, so it must be better, right? It's not just ripping, it's high-resolution ripping that counts. With AIFF each of those 16 bits will have so much more resolution that you have to be almost deaf to not be able to hear it...
Here's a couple hints to Linux programmers:
Have end users download, then run an executable that automatically configures/compiles/installs itself, and comes with its own libraries.
I already can this on my linux system, and you could on yours. On my system it's called dpkg or apt, on yours it was called rpm. While.rpm's or.dpkg aren't exactly executables, they contain executable scripts that help set the system up correct for you, and with correct libraries.
Your complaint would be better addressed to half-life programmers. Why are you blaming linux for making it hard to install half-life? Are you blaming windows for making it hard to install xboing too? Was half-life even supported on linux?
Make it run in the GUI. If it's so hard, WHY CAN ALMOST EVERY WINDOWS PROGRAM DO IT?
Windows has larger marketshare, and therefore it makes more sense for developers to create a good installer (in linux terms: "package") for windows than for linux. Moreover, linux isn't distributed by only one company. There are a lot of different versions, packaging systems, etc, to support.
Finally, windows and linux are different. Just because it is possible to run a few windows programs in an emulator under linux, doesn't mean it's always a good idea. (Neither is cygwin a full good alternative to linux).
If half-life isn't working under linux, you know what to do to make it run. Use windows for running half-life, and stop complaining.
How about letting me into my own system without root? It saves time. Either hackers erase my OS for fun or I erase it out of frustration.
Fine. As root, enter "passwd -d root". But don't complain to me if you get into trouble later. Should be as safe as a default Win98 install though...
Maybe my mouse should work every time instead of just moving in vertical lines. Maybe I should be able to plug and play my mouse, like in Windows.
Yes. Blaim Mandrake.
Perhaps Linux could not crash because of USB switching, like XP. I'm thinkin' that I should be able to reconfigure my mouse, that doesn't work, with a keyboard, that does, by tabbing through an interface.
You mean XP crashes because of USB switching?
Needless to say, I am now a happy Windows XP user. I stick in the CD, reformat some partitions, and away it goes. All I need to do is enter codes. How is that hard? Furthermore, I have been using a pirated German version of XP with almost no English in it. I don't know German. Yet it's STILL easier to use than Linux. Linux has given me a nasty taste in my mouth; I hope I never have to go back.
So how exactly is it "easier to use"? Because you already are used to running windows, and even if the text is in german, the user interface is still more similar to what you are used to, then linux? Well, if you had been grown up using unix, I'm sure you would prefer to use a german pirated unix rather than windows in your native language. So exactly what does this tell you? That measures of "easier to use" makes no sense unless we take into account the users previous experience with computers?
Yes and no. In 1987 the Roland MT-32 was *THE* synth to have. Unfourtanatley you had to be pretty wealthy or lucky to have one -- their new price was somewhere around 600$. The MT-32 was light years ahead of then-current sound cards, and even today it still sounds pretty good.
Sounds like you're right. After some further research, it sounds like the MT-32 was more or less a D-50 for the sequencing and gaming market. Some minor preset differences, and completely useless without a computer, but still, more or less the same hardware. The D-50 is after all one of the big classics people still like to drag around or keep in their studio.
Now, despite Rolands advertizing, the D-50 never sounded very good when emulating analog instruments, which is what sample-players and GM soundcards do pretty well. But as a synth in it's own right, it is still somewhat sought after. So yes, if you had music written especially for it, with custom-made patches, it is likely that you will never even get close to that on a GM soundcard.
I suspect that if the author(s) ever clears the legalities up with Roland, and modify it to emulate a D-50, and add a DXi or VSTi interface, it would actually be pretty easy to sell that thing... Wouldn't have to be crazy at all!
My understanding is that this is some sort of MIDI synth device. I've always wondered what exactly what these things did that was special. Surely any old soundcard also can do MIDI synth, as well as software like timidity?
It's a pre-GM synth. It contains more or less the same set of sounds, but in a different order. Some very old DOS games probably support it, and not GM soundcards or modules. If you only care about functionality, it would be easier to just remap the sounds, and maybe choose an old and awful-sounding soundset for timidity or other software synth. You would have to be half-crazy to start such a project anyway, but aren't most people doing emulators that anyway?
Either way, it seems strange to want to use old synth equipment -- either case seems to be outclassed by modern software. Yet I know that people pay crazy amounts of money for it.
The only real possibility I can think of is if you spent years with a synth and don't want to throw away all that experience...
Probably some truth to that. But it is also possible that they actually enjoy the sound and "feel" of them. Many do, even if they are not old enough to have used them when they were new. And if you want to sound like Vangelis or Kraftwerk, you might as well use the same equipment (which was NOT a cheap MT-32 by the way, the old classic synths sell at prices mostly comparable to what they were originally sold at). Compare it to how strange preferences people have for guitar amps, the older and crappier, the better:-)
Besides, untill a few years ago, most new synths were just samplers and everyone sounded similarly, so there actually was some sense to choosing an old synth if you enjoyed programming new sounds, or twitching the knobs to change the sound in real-time. Today, there are plenty of more modern alternatives.
It also means that from now on it's unsafe for musicians to sell records that contain samples from a Roland sound card. And this means musicians will stop buying Roland gear if this case gets more media attention.
I assume that by "records", you mean "sample-CD's", and not actual music (or you would sound like an idiot). For your information, that has always been a grey area. If you clone factory-made patches, and sell them, you'd better get permission from the manufacturer, whether it's Roland or not. Or just hope that they don't discover you, or care enough about it to take you to court. But even sampling is quite different from extracting the raw patches from the hardware, and even if sampling was ok, extracting would not be legal.
Musicians rarely have any use of samples of an MT-32 piano or timpani, they are more interested in samples of an actual piano or timpani (or an actual piano or timpani) But then again, I've seen sample CD's with samples of kitchenware, so you can use a $5000 sampler to reproduce the sound of two spoons hitting each other, whatever the advantage would be... I would suspect that most sample-CD's with samples of factory-made patches of favourite synths are either not entirely legal, or that part of the price you pay for it goes to the original instrument manufacturer for paying royalties.
Creating a cool patch for an analog synth, and then sampling it is always ok, and also quite common in the sample-CD arena. Samples of factory made patches is like samples of samples, a grey area.
For those of you who don't know: the MT-32 is a synthesizer module. So it's normal use is to generate sounds that people are going to use on commercial records. If you buy the box, you get the sounds. There are tons of sample CDs out there that contain samples of Roland instruments. So why is the PCM (sound) set of an MT-32 suddenly such a problem to them?
Obviously, because there is a difference between (a) making music using an MT-32 as an instrument, (b) taking an MT-32, connecting it to a midi keyboard and a hardware sampler or soundcard, and then sample every sound at various pitches, loop them, and build fully workable patches from it, and (c) just using extracting the actual finished patches from the hardware.
Alternative (a) is always legal. Alternative (b) is questionable, but quite common. Personally, I would not distribute such patches widely unless I got written permission from the manufacturer, but this depends on a lot of things, such as whether the hardware synth you are using uses samples or not (if not, it should be ok, as long as you created the patch yourself (the MT-32 does not fit into this category, by the way)).
Alternative (c) is clearly very different from the last two. Unless he has permission, or there actually is no copyright on the samples, then he is in big trouble. Simple as that!
Oh yeah, if you can find a legal sample CD containing all the MT-32 sounds as fully workable patches in a format that is possible to convert to whatever the emulator uses, with a copyright that allows redistribution, then that is of course also ok, but I kind of doubt that exists. (If I were to create a sample-CD cloning an entire rom-based sampler, I would probaly choose something a bit more interesting than the MT-32, and besides, I would never get permission from Roland to allow it to be distributed freely:-)
Censorship is removing objectionable, or unsuitable content. Preventing someone from shouting "Fire!" in a crowded theatre isn't censorship because it isn't that the words are objectionable, it's that the result of shouting them will cause chaos and damage. Likewise, Verisign's wildcard caused damage and so it was blocked.
I fail to see that there's anything crystal clear about most peoples definition of censorship, or the one you linked to.
Saying that something "causes damage" is no excuse for it. Do you think that people sensor each other just for fun? The reason people start censoring stuff is of course to limit "damage". And whether the damage is "people running around in theatre", "dictator looses power", or "kids learn to swear" doesn't mean anything as long as the definition you pointed to cares.
There's no such thing as "free speech". Even political censorship is unavoidable in most countries. For example, advocating and plotting a revolution is usually forbidden. (That being said, there are different degrees of "free speach", and "cencorship", and we as a people and members of the society should always aim for being as open as possible.)
But just to get back to the original topic... I agree that this wasn't censorship. They are fully allowed to say whatever they want, just not there...
Hmm, funny, it doesn't work through my X replacer. I have written a program that will replace every X, but when I run your program through it, it just doesn't work...
You are looking at things ass-backwards. These guys have written an Xlib compatibility library for an existing GUI system, which happens to have some custom message passing layer underneath.
No, you are looking at things ass backwards. These guys have written some nice-looking web-pages where they have written a lot about software they haven't even started writing. They certainly haven't written a full Xlib compatibility library yet, as they don't even have a windowing system to write it for (or probably even a running kernel to run the windowing system on).
I quickly looked through some of their CVS, and found nothing that wasn't tagged "original L4" or something like that. But it's possible they have made one or two changes.
I will compliment them for their web-designer skills, though. For a moment. they fooled even me into believing this was a real project, that I just hadn't heard about. But at this stage in a real project, you should spend your time coding, not making webpages with "forums", and "login", or "register". They are two developers, they don't even need "mailing lists".
Is it really so hard to imagine a Masters level student who hasn't encountered Java before?
I don't think it's that odd.
No, it isn't. But it's really hard to imagine a masters level student that isn't capable of learning java fast.
I assume what is wanted is something beyond Learn Idiotic Java Unleashed In 24 Hours Bootcamp.
Well, then we have different assumptions. I assumed he wanted to teach good programming using java as the language of choice, not that he wanted to make a class of java language lawyers (something that would definitely require prior exposure to the language anyway).
Finally, even though you cover java in the first two weeks, doesn't mean that people should stop learning after that, but it should be more than enough to get up to speed.
I stand corrected in the case of killing. But there's still a difference between that and this case. Adrian Lemo didn't involuntarily hack those sites (and neither did he do it in self-defence). If you kill some asshole for utilitarian reasons, you will still be prosecuted (war and carrying out a death penatly are exceptions, though...)
What you are looking for doesn't exist, ok? If you want to teach master students program design, give them a book on program design, regardless of language. Special java idioms can be covered by your own lecture notes or another textbook, but there are few that need to be taught.
For master students, picking up java should be trivial, and you should not spend time on teaching it to them. To avoid too many complaints, cover some introductory java book such as suns java tutorial in the first two weeks, and assume they know it by then. Better yet, cover only the parts of java you will use in those two weeks, and let the students choose their own favourite textbook.
I've got a midsize Linux project which uses a lot of STL and other C++ template code. Even considering this, I end up with a lot bigger text (generated code) segment than expected.
Huh? What did you expect? Templates lead to bloat per definition. That's what they do: a lot of binary code is generated by a small amount of typing. If bloat becomes a problem: redesign.
I know the information about the amount of code generated for each class is in the objdump, but prying it out by hand is a problem when you get five line long template invocations and hundreds of methods to wade through. Can anyone can recommend some tools that analyze binary or objdump output and summarize the amount of code generated for each class, including each unique template or STL class?
I wish I did. But most likely, I think you are fucked. Without an understanding of the code, it's hard to debug template problems. Find out where the bloat is by analysing the source code, not the binary.
Slashdot Mirror
Well, if you are saying that the driver-wrapper actually reads the x86 binary, and interprets that, then you really have a marvel of engineering.
But what makes sense, and would probably be possible to do is to just create a wrapper. The driver expects certain "hooks" to be able to talk to Windows. The wrapper provides them, and also handles communication with the linux kernel. Since this is so lowlever, it would probably not even require a single code of wine. But at the very minimum, it would require some assembly to translate between the varying calling conventions. If you are unlucky (most likely), it will also require keeping some state, as the low-level interface for NIC drivers is probably quite different in windows and linux.
I doubt most printers have an NDIS layer. That is, unless the printer comes as an ISA, PCI, or PCMCIA card, and doubles as a networking card.
Ok, let's start with resilience. Quoting from fork benchmark: "OpenBSD does not scale at all, and even panics under high load."
Uhh, high-end tapes have always had faster write-speeds than hard-disks. If all you want to do is write data fast, use tapes, or maybe a SAN or something like that. But then again, it's possible we have different opinions about what constitutes "high-end".
Well maybe. If your nuclear power plant depends on it, you are hopefully extremely paranoid about replacements. A failure may result in more than just a lost time incident (which by itself would be pretty bad), it could actually be catastrophic. You would have to do extensive testing of the emulator and the new hardware before accepting substitutes for the real thing. It might end up being more work than writing a new version and testing it.
A more likely scenario is to use it for less mission-critical stuff, but still stuff that you need available most of the time, but doesn't seem important enough to warrant a huge investment. I.e. replacement for ancient data loggers, etc...
On the other hand, I'm pretty sure most of them are used by hobbyists...
If somebody decided to put an Alpha machine into an important application, they would definitely need an emulator for it.
Excuse me! What planet are you from? If you can point to just one example of a any company or institution that refuses to use any computer before it can be emulated on another, I will happily go kill myself. Even long after an ISA dies, you can usually get spare parts from other systems taken out of service. Or you could buy all spare parts you needed in advance. As long as you are dealing with computers, nobody can plan beyond a 20 year lifespan.
And remember, it's not too hard to emulate a 5-year-old machine at realtime speeds.
Yes it is. There's a lot of quirky details with emulating real hardware. Computers grow more complicated every year, and it's not just the CPU we are interested in emulating. Writing an emulator for, say a 5 year old x86 is a major undertaking (don't say that writing bochs was "not too hard").
And if you want to make sure it runs your mission-critical tasks properly, you'd better make damn sure every detail is perfect. And that includes emulation or interfaces for any proprietar or otherwise unavailable or "weird" hardware you might have added.
If your vendor dies, you can just move applications to a new platform and the users will not notice a difference.
Well, the VM is a platform too. If the vendor dies, you either have to find another vendor, or start porting. There were no greater risc involved in choosing Alpha. After being slaughtered in '97, it's still available, and will be for yet another generation. And even after it's completely dead, you can still find used ones. If you absolutely need an instruction set architecture that lives forever, you know where to find it.
The Alpha was formerly Compaq and even before that a Digital invention. HP has their PA-RISC architecture, of which Itanium was planned from the start to replace (one of the design requirements for Itanium was that a software translator for binary PA-RISC code was made possible).
Furthermore, as far as I know, the Alpha is still produced by Intel, not by HP/Compaq/Digital, as Compaq sold their alpha plants, personell and all associated IP to Intel (and thus avoided a lawsuit, as well as ensuring the Alphas future for a few years). There were also plans for a Itanium version of Tru64 (formerly Digital Unix), but I am unsure as to whether it was ever commercialized.
All in all. It seems like a pretty sound business decision to me. This is what "they" have planned all along, for many years, whether "they" are Digital, Compaq, HP, or Intel.
Yeah, I remember the same thing. Unfortunately, it didn't age well. Don't know if that should tell us something... Maybe that marketshare is more important than technical benefits? May all future good designs rest in peace!
If it's the same spammers who go on and on doing it, I think it's safe to guess they have found a formula that works, and are getting rich by doing it. A 0.0001% return rate, means that they need to earn 1000000 times the cost of sending one email per sale. Considering that sending email is basically free, and that 0*1000000 is still 0, this means that even low success rates can give rise to high profits.
For the current generation of typical computers, 50, 100, or 300 processors is still a lot more than what is common. Mostly, it is 1. Meaning we still have quite a lot of speedup to gain before Amdahls law makes it all worthless.
Systems with more than 1 processor today are usually servers or running other kinds of easily paralellizable processes.
The main reason most of todays systems avoid having too many processors is probably not Amdahls law. My guess would be a combination of history, market demand (will it run my software (and better?)), and the obvious problem of memory bandwidth which makes multiple processors cost more than just the processor cores, if you want to keep them busy.
Uh, what would you expect. When "cutting edge" eventually gets affordable, don't you suspect that someone would offer something a little bit faster that costs just a few hundred times more?
Considered the length of the grant-cycle I usually have outdated technology... I suppose if this sort of technology becomes the leader, I would still have to have the resources of a large research university to get anything done. At least the way it is now, my home machine is faster then the one at work!
Then rent some computer time from somebody that has bought a decent machine. It's still possible to do that, right? :-)
While obviously true, it means very little in practice. Mostly, tasks that take a lot of time are easily converted to paralell subtasks by a human. And we certainly don't need "perfect" paralellism. For some tasks, it's sufficient with "faster", and for all tasks it's sufficient with "faster at same or lower cost".
Yes, I have to agree with you Michael. AIFF is so much better than WAV. After all, it's less known, and is mentioned in stereophile, so it must be better, right? It's not just ripping, it's high-resolution ripping that counts. With AIFF each of those 16 bits will have so much more resolution that you have to be almost deaf to not be able to hear it...
I already can this on my linux system, and you could on yours. On my system it's called dpkg or apt, on yours it was called rpm. While .rpm's or .dpkg aren't exactly executables, they contain executable scripts that help set the system up correct for you, and with correct libraries.
Your complaint would be better addressed to half-life programmers. Why are you blaming linux for making it hard to install half-life? Are you blaming windows for making it hard to install xboing too? Was half-life even supported on linux?
Make it run in the GUI. If it's so hard, WHY CAN ALMOST EVERY WINDOWS PROGRAM DO IT?
Windows has larger marketshare, and therefore it makes more sense for developers to create a good installer (in linux terms: "package") for windows than for linux. Moreover, linux isn't distributed by only one company. There are a lot of different versions, packaging systems, etc, to support.
Finally, windows and linux are different. Just because it is possible to run a few windows programs in an emulator under linux, doesn't mean it's always a good idea. (Neither is cygwin a full good alternative to linux).
If half-life isn't working under linux, you know what to do to make it run. Use windows for running half-life, and stop complaining.
How about letting me into my own system without root? It saves time. Either hackers erase my OS for fun or I erase it out of frustration.
Fine. As root, enter "passwd -d root". But don't complain to me if you get into trouble later. Should be as safe as a default Win98 install though...
Maybe my mouse should work every time instead of just moving in vertical lines. Maybe I should be able to plug and play my mouse, like in Windows.
Yes. Blaim Mandrake.
Perhaps Linux could not crash because of USB switching, like XP. I'm thinkin' that I should be able to reconfigure my mouse, that doesn't work, with a keyboard, that does, by tabbing through an interface.
You mean XP crashes because of USB switching?
Needless to say, I am now a happy Windows XP user. I stick in the CD, reformat some partitions, and away it goes. All I need to do is enter codes. How is that hard? Furthermore, I have been using a pirated German version of XP with almost no English in it. I don't know German. Yet it's STILL easier to use than Linux. Linux has given me a nasty taste in my mouth; I hope I never have to go back.
So how exactly is it "easier to use"? Because you already are used to running windows, and even if the text is in german, the user interface is still more similar to what you are used to, then linux? Well, if you had been grown up using unix, I'm sure you would prefer to use a german pirated unix rather than windows in your native language. So exactly what does this tell you? That measures of "easier to use" makes no sense unless we take into account the users previous experience with computers?
Sounds like you're right. After some further research, it sounds like the MT-32 was more or less a D-50 for the sequencing and gaming market. Some minor preset differences, and completely useless without a computer, but still, more or less the same hardware. The D-50 is after all one of the big classics people still like to drag around or keep in their studio.
Now, despite Rolands advertizing, the D-50 never sounded very good when emulating analog instruments, which is what sample-players and GM soundcards do pretty well. But as a synth in it's own right, it is still somewhat sought after. So yes, if you had music written especially for it, with custom-made patches, it is likely that you will never even get close to that on a GM soundcard.
I suspect that if the author(s) ever clears the legalities up with Roland, and modify it to emulate a D-50, and add a DXi or VSTi interface, it would actually be pretty easy to sell that thing... Wouldn't have to be crazy at all!
It's a pre-GM synth. It contains more or less the same set of sounds, but in a different order. Some very old DOS games probably support it, and not GM soundcards or modules. If you only care about functionality, it would be easier to just remap the sounds, and maybe choose an old and awful-sounding soundset for timidity or other software synth. You would have to be half-crazy to start such a project anyway, but aren't most people doing emulators that anyway?
Either way, it seems strange to want to use old synth equipment -- either case seems to be outclassed by modern software. Yet I know that people pay crazy amounts of money for it.
The only real possibility I can think of is if you spent years with a synth and don't want to throw away all that experience...
Probably some truth to that. But it is also possible that they actually enjoy the sound and "feel" of them. Many do, even if they are not old enough to have used them when they were new. And if you want to sound like Vangelis or Kraftwerk, you might as well use the same equipment (which was NOT a cheap MT-32 by the way, the old classic synths sell at prices mostly comparable to what they were originally sold at). Compare it to how strange preferences people have for guitar amps, the older and crappier, the better :-)
Besides, untill a few years ago, most new synths were just samplers and everyone sounded similarly, so there actually was some sense to choosing an old synth if you enjoyed programming new sounds, or twitching the knobs to change the sound in real-time. Today, there are plenty of more modern alternatives.
I assume that by "records", you mean "sample-CD's", and not actual music (or you would sound like an idiot). For your information, that has always been a grey area. If you clone factory-made patches, and sell them, you'd better get permission from the manufacturer, whether it's Roland or not. Or just hope that they don't discover you, or care enough about it to take you to court. But even sampling is quite different from extracting the raw patches from the hardware, and even if sampling was ok, extracting would not be legal.
Musicians rarely have any use of samples of an MT-32 piano or timpani, they are more interested in samples of an actual piano or timpani (or an actual piano or timpani) But then again, I've seen sample CD's with samples of kitchenware, so you can use a $5000 sampler to reproduce the sound of two spoons hitting each other, whatever the advantage would be... I would suspect that most sample-CD's with samples of factory-made patches of favourite synths are either not entirely legal, or that part of the price you pay for it goes to the original instrument manufacturer for paying royalties.
Creating a cool patch for an analog synth, and then sampling it is always ok, and also quite common in the sample-CD arena. Samples of factory made patches is like samples of samples, a grey area.
Obviously, because there is a difference between (a) making music using an MT-32 as an instrument, (b) taking an MT-32, connecting it to a midi keyboard and a hardware sampler or soundcard, and then sample every sound at various pitches, loop them, and build fully workable patches from it, and (c) just using extracting the actual finished patches from the hardware.
Alternative (a) is always legal. Alternative (b) is questionable, but quite common. Personally, I would not distribute such patches widely unless I got written permission from the manufacturer, but this depends on a lot of things, such as whether the hardware synth you are using uses samples or not (if not, it should be ok, as long as you created the patch yourself (the MT-32 does not fit into this category, by the way)).
Alternative (c) is clearly very different from the last two. Unless he has permission, or there actually is no copyright on the samples, then he is in big trouble. Simple as that!
Oh yeah, if you can find a legal sample CD containing all the MT-32 sounds as fully workable patches in a format that is possible to convert to whatever the emulator uses, with a copyright that allows redistribution, then that is of course also ok, but I kind of doubt that exists. (If I were to create a sample-CD cloning an entire rom-based sampler, I would probaly choose something a bit more interesting than the MT-32, and besides, I would never get permission from Roland to allow it to be distributed freely :-)
I fail to see that there's anything crystal clear about most peoples definition of censorship, or the one you linked to.
Saying that something "causes damage" is no excuse for it. Do you think that people sensor each other just for fun? The reason people start censoring stuff is of course to limit "damage". And whether the damage is "people running around in theatre", "dictator looses power", or "kids learn to swear" doesn't mean anything as long as the definition you pointed to cares.
There's no such thing as "free speech". Even political censorship is unavoidable in most countries. For example, advocating and plotting a revolution is usually forbidden. (That being said, there are different degrees of "free speach", and "cencorship", and we as a people and members of the society should always aim for being as open as possible.)
But just to get back to the original topic... I agree that this wasn't censorship. They are fully allowed to say whatever they want, just not there...
tr xX yY
You are looking at things ass-backwards. These guys have written an Xlib compatibility library for an existing GUI system, which happens to have some custom message passing layer underneath.
No, you are looking at things ass backwards. These guys have written some nice-looking web-pages where they have written a lot about software they haven't even started writing. They certainly haven't written a full Xlib compatibility library yet, as they don't even have a windowing system to write it for (or probably even a running kernel to run the windowing system on).
I quickly looked through some of their CVS, and found nothing that wasn't tagged "original L4" or something like that. But it's possible they have made one or two changes.
I will compliment them for their web-designer skills, though. For a moment. they fooled even me into believing this was a real project, that I just hadn't heard about. But at this stage in a real project, you should spend your time coding, not making webpages with "forums", and "login", or "register". They are two developers, they don't even need "mailing lists".
No, it isn't. But it's really hard to imagine a masters level student that isn't capable of learning java fast.
I assume what is wanted is something beyond Learn Idiotic Java Unleashed In 24 Hours Bootcamp.
Well, then we have different assumptions. I assumed he wanted to teach good programming using java as the language of choice, not that he wanted to make a class of java language lawyers (something that would definitely require prior exposure to the language anyway).
Finally, even though you cover java in the first two weeks, doesn't mean that people should stop learning after that, but it should be more than enough to get up to speed.
I stand corrected in the case of killing. But there's still a difference between that and this case. Adrian Lemo didn't involuntarily hack those sites (and neither did he do it in self-defence). If you kill some asshole for utilitarian reasons, you will still be prosecuted (war and carrying out a death penatly are exceptions, though...)
For master students, picking up java should be trivial, and you should not spend time on teaching it to them. To avoid too many complaints, cover some introductory java book such as suns java tutorial in the first two weeks, and assume they know it by then. Better yet, cover only the parts of java you will use in those two weeks, and let the students choose their own favourite textbook.
Huh? What did you expect? Templates lead to bloat per definition. That's what they do: a lot of binary code is generated by a small amount of typing. If bloat becomes a problem: redesign.
I know the information about the amount of code generated for each class is in the objdump, but prying it out by hand is a problem when you get five line long template invocations and hundreds of methods to wade through. Can anyone can recommend some tools that analyze binary or objdump output and summarize the amount of code generated for each class, including each unique template or STL class?
I wish I did. But most likely, I think you are fucked. Without an understanding of the code, it's hard to debug template problems. Find out where the bloat is by analysing the source code, not the binary.