Are you honestly trying to suggest that double clicking an install file or dragging and dropping an install file is somehow only easier than the mess of configure/make/compile simply because it is familiar? Really? Now you're just not being intellectually honest.
Let's see, typical usage, (using rpm based system), say I want blah, yum install *blah* -y however long after it downloads and installs for me later, I have it, could have done anything I want in the mean time while it was doing it's thing.
windows, i have to hunt it down on google, download it, then when I remember that I downloaded it, initialize the install process myself as opposed to having it automated..
for one or two things, this isn't so bad... getting windows from fresh install to a usable state by doing that though, is painful and time consuming.
General rule of thumb, these days you only have to compile yourself if you're doing some kind of fun mad science (with me it's usually making cross-compilers for strange architectures)
While I'm a very atypical case, I am used to configure/make/install routine, and I recently used a mac, the click and drag interface was so foreign to me the first time I was waiting there thinking it was just thinking about installing.
Also, in regards to security, any popular project will have quite a few people studying it's source, it only takes one of those to notice a problem (as you said, spyware etc) to notify everyone else where it will promptly be resolved... but, this never happens because any malicious changes are immediately noticed in the changelogs of the revision control software. Everyone monitoring each other keeps people honest, you can't do that in closed source software.
People spend years getting a reputation being a good coder, few are willing to lose that simply to get a little cash. When they will be caught sooner or later.
e.g. rt2500 -- there are open source drivers available, but you have to download them, compile them and install them yourself; the lack of a stable ABI makes the process difficult and time consuming, putting it beyond the scope of an average user).
I have an rt2500 based one and it works fine, didn't until about six months ago when the drivers went mainline, but anyway back to the main point
you seem to have missed the point, certification would be great, but a stable ABI is not needed for it.
Do you really think that magically every piece of hardware work would if we had a stable kernel ABI? there would still be lots of hardware not supported, even with a certification ("blah works on linux") program that would still be the case but at least you could tell what is and isn't supported before you purchase it.
The general idea with this isn't "get everything working" it's "let people know what will and won't work".
As you've said currently when you buy a piece of hardware you can never be sure what chipset etc you're getting or whether it will work. Add in some manner of linux tag where you can only add it to the product if the mainline kernel detects and uses it, and you would know what will or won't work out of the box, changing to an unsupported chipset would be grounds for removal of the use of the tag, make sense?
All of this would allow people to identify what works, and what doesn't, without a stable ABI, the reasons the ABI isn't stable are technical ones, I see no reason to gimp the linux kernel at the request of people who are not part of it's main development.
Package management is wonderful, but we need to standardize the damn things. I vote for Apt-RPM. Choice is good and wonderful, but not when it is considering package formats. Just pick one so we can finally just post a "Linux" binary on the web that works with every package management system seamlessly. How kick ass would that be?
Even if you only had one format, it would not work that way, each package in a repository is connected to dependencies on others, all of which could be compiled with support or non-support for specific libraries etc. You still would not be able to put one package there and have it be supported by all in all cases. Each package as it's added is tested to make sure it functions with the other packages in the repository.
What you said though, seems to be the only reason people want to have one package manager to rule them all. When it is false, what other advantages besides trivial ones would only having one package manager out there have?
Audio is a mess, and Pusleaudio is not the band-aid that will cure it; at least not in the state it is in. It doesn't help that distros can't package it correctly, but there are too many switches and levels for even the most simple of tasks.
See here we have different tools for different levels of functionality, according to you pulseaudio has too many switches and levels etc, well, pulseaudio is useless for anyone doing anything remotely serious with audio, way too much latency, jack is pretty much the only game in town so far as that is concerned, and it functions wonderfully, but would introduce even more complexity because of the flexibility it has.
Many things can get resolved over time, but conflicts of design goals are one of those things that do lead to different applications because of different needs. Pulse-audio seems to be trying to be everything to everyone, and failing horribly in the process for most, but working good enough for those who don't care.
a stable ABI is not equal to a certification program, which is more so what you would like.
Linux already has the largest in-built hardware support of any os, only as you correctly point out you won't know if it works until you try it. So why not test against a standard kernel and if it works give it the linux stamp you so want?
Because the vast majority of hardware manufacturers, especially in the home markets, are NEVER gonna give you their code. It simply isn't in their best interests and it opens them up to the risk of litigation by patent trolls
The card vendors no, the chipset manufacturers, the majority of them will give you specs if you demand them, why wouldn't they? the people purchasing the chipsets for use in cards need the specs to effectively use them. This is how most of the drivers in the linux kernel for random hardware is made, there are only a few notable hold-outs.
Having the drivers in kernel and frequently audited and updated is one of the linux kernels biggest strengths, running closed source random code in kernel mode from third parties is a serious security and stability risk. Most modern windows blue screens aren't caused by windows, but by shitty divers written by third parties.
Still, I think you should perhaps gather, that having a stable ABI will do sweet crap all in regards to linux driver uptake, and that what you really want is a linux hardware certification program, which would solve the peripheral problems you've mentioned, once a piece of hardware is supported in the linux kernel, that support is very very rarely removed.
Package management should be confined to a common package format.
I keep hearing this all the time from people, but they fail to see it as a non-issue. Repository packages have to test their requirements against the other packages and it's all an interconnected system for a given distribution. People seem to think 'if redhat went with.deb we could use fedora packages in debian without any fuss!!' not the case. And making packages for the different formats is trivial, and is done as you can see that there are pre-packaged forms of most poplar software for all the major distros.
As for sound, that is a more legitimate gripe however going back to OSS is not the way, OSS is way too limiting in it's capabilities, The pro audio sector pretty much dictates alsa + jack, but the 'desktop' crowd seem to be standardising on alsa + pulseaudio, which has so much latency it isn't funny, not to mention unable to do half the things jack can in regards to dealing with audio streams
Which is why i have said time and time again there needs to be a stable ABI and a "Tux the penguin" certification process.
Certification process fair enough, but a stable ABI is not needed for that, any piece of hardware that has a recognized in kernel tree driver driver should simply be plugged in and see if it works, if it does without any real issues, certification can be done
Trusting random companies with ring 0 privileged code your machine is a big leap of faith when you can't see the code, almost all of the bsod's you see these days on windows aren't microsoft's fault at all, but the fault of shitty drivers by third party companies. Some of us like the quality ensured by having in kernel frequently audited drivers
But still, allowing binary blobs is not needed for certification that *blah* works on linux. Linux does have the largest in-built hardware support of any modern os.
At the end of the day, the people that produced the content should be entitled to reap any benefits from it.
Just how will they reap the benefits of it 75 years after they are dead?
Its not like artists are actively prevented from creating content.
But.. they are, if practically eternal copyright had existed before, disney would not have been able to make most of it's movies. Just as people today cannot take those stories and be creative with them making their own adaptations.
This may surprise you, but very little of what we make is actually new, it is merely different combinations of already existing ideas, when you disallow the partial use of existing ideas, you are stifling creativity.
The idea of copyright is to give people incentive to create new works, what incentive is there to create new works when you can sit on already completed works for longer than a lifetime?
So you do see it there. Why do you think that the hardware is moot?
Why do you think hardware matters, when we are talking about software?
So, leaving aside the "but we know how to do that" argument, what's not patentable about the above when explicitly performed by a specific computing device?
So.. you are going to patent something on x86, have a separate patent for arm, separate patent for MIPS, for doing the exact same thing mathematically just expressed in a different language, for a different hardware chipset, are you? I highly doubt it.
example using Seti@home on your ps3 is not a novel and new idea compared with doing it on x86, it's just the same thing on different hardware. And even doign it on x86 isn't being novel, it's just doing maths on something that is designed to do maths.
I fail to see how doing maths on computers changes the fact it's just doing maths, just as I fail to see how doing maths on an abacus is not just doing maths (if the abacus were invented in modern times, it would have been patentable also)
if I had a board game, now this board game did something awesome, and was somehow patentable, and I figured out a fool proof way of playing this board game using maths, making instructions on how to, to you would those instructions be patentable?
That is your argument, that instructions to use something specific are patentable, I have no doubts this will not change your opinion, but it may make you think about what you are proposing a bit more.
No, I think that math that is actually expressed in an instruction set and explicitly requires the processors, memory and circuits that you admit are patentable is also patentable.
You just said no, then essentially repeated what I said in agreement... odd, you just said that you think maths that is expressed in an instruction set is patentable. The only addition being it MUST be tied to the hardware, You don't seem to get that the instruction set is moot, it's merely a language to express the maths in. Also randomly, I can read x86 hex code(slowly).. does that make me a computer and patentable? (/sarcasm)
so, you really don't see the difference between hardware and software running on that hardware do you? (also, the hardware could only be patented if they did something funky and new, most likely something in the way it was constructed or some such)
what you described in your example would never be accepted as a patent, it would basically cover the storing of anything in memory which computations could be done on, too vague, and it wouldn't even be patenting the software, just patenting a method of loading and executing software.
When it comes down to it, when you patent software, you are patenting maths behind the function of the thing that is being patented, or if the patent holder is really lucky, even the idea that something can be done (example, 1 click purchasing patent).
It's not mathematics, because maths and logic don't contain circuits, processors, and memory.
Yes, maths does not contain those things, and ways of implementing processors, memory etc ARE patentable, and should be, this aspect has.. what to do with software?
Software does not contain circuits, processors, or memory, it may need them to run but it does not contain them. Software itself is a set of bits that tells a set of hardware what logical and mathematical operations to do. Which, mind you, is already covered under copyright.
Patents are about implementations of ideas, how are ideas implemented in software on a computer? through mathematics and logical operations.
You seem to think that just because the maths is expressed in an instruction set that hardware can decode and execute, that the maths should be patentable, I respectfully disagree./p.
Re:Surely Slashdot can get cracker vs hacker right
on
How To Hire a Hacker
·
· Score: 1
In essence you are arguing that a words definition comes from common usage.
After listening to some of the tripe that comes out of teenagers mouths these days one would wonder if you could say that again with a straight face afterwards.
In regards to the term 'hacker' almost everyone who works in the industry to some extent knows the geeks version. Only those that don't have exposure get it incorrect, but most lay people don't understand trade-specific terms anyway. Does that mean that the people who study the trade are wrong, and the average person is right? due to their collective lack of knowledge?
In terms of software, while it used to be really bad, I think US patent law is moving in the right direction -- it looks like ultimately they'll allow software patents, but they're going to have to be a *lot* less general and a *lot* more in depth. Which is a good thing.
Interesting, what is your stance on the patenting of mathematics then? since all computer programs essentially come down to maths and logic.
Mass effect may be a decent game, but baldurs gate 1 and 2 are considered by many to be the gold standard of rpgs, the attention to detail and quality in them is pretty darn hard to equal, let alone surpass.
so wait a second.. you are saying when everyone else follows the normal standard, and apple does the weird and strange thing with custom parts, that everyone else should follow suit?
here's an idea, get a stereo (or make an adapter to the amp) that allows a standard 3.5mm stereo plug. It was your choice to limit your cars stereo to interfacing with an ipod by getting one with an ipod connector as opposed to something more.. mainstream
I know what you're talking about: Rudolph's dumper.
I used an original gameboy advance media player, with modified firmware, and I had not heard of rudolf's dumper until you mentioned it then, I had a tool around 2005'ish that could dump ds firmware, ds slot sram, and ds slot rom, very handy multi-functional tool, featured a debugger also. Cannot for the life of me remember the name of it but if I can remember I will post in a reply.
Any ideas on how to build an NES copier?
best bet to follow petermgreen's advice, my main experience is snes where we don't have memory mappers, just silly co-processors in cartridges:)
There are at least a dozen different ways to make cartridge based games self destruct their data if they're opened. You can't get the ROM off it if a system wipes it any time oxygen is sensed inside the cartridge which has a vacuum in it.
sure you can, I can dump my legitimate games onto cf card using my actual ds.. you do realize that for the cartridge to be usable the system has to be able to read the data... right?
dumping does not involve removing cartridge chips these days (ok.. well... arcade games sometimes) it either involves putting the cartridge into an original system that's running a dumper program, or making something yourself that has a cartridge port that can read it.
First, $600 is not going to buy you production 24/7 server quality machine that Mac Pro is.
quite likely, but $1500 will, that's still 1/3 of the cost, granted that neither the mac pro or that machine would be 'server' class, but they would be very similar in performance
For a serious, quality server, hot pluggable storage,redundant hot pluggable power supplies and cpu's are a requirement. Pluggable storage and power is frequently covered by many $6-8k rack mount systems (including x-serve) but hot pluggable cpu's will cost you, only IBM and SUN systems really do that, and they are pricey.
If you really want to use it to the fullest you have to install Windows 64 bit on it.
being on slashdot, you would of had to have heard of linux yes?
fully decked out mac pro (just added hardware bits on their customize section AU country though) comes to $26,199 AU (around $22,100 USD) for that much cash I'd be expecting a shit-tonne better system.
Base mac pro here is $4.5k with one quad core processor. 3gb ram, etc, still a nice machine, but you can make something better for about a grand and a half, and flickiestrife's $600 machine is better than it (includes a monitor even).
guess my bike is a bit odd in that the weight is extremely low to the ground in comparison to other bikes, thusly I can brake harder before the rear end lifts, as well as I have somewhat.. large front and rear tyres for the weight of the bike
I do completely agree that a sports car will out brake a motorcycle, but most people don't drive sports cars around the place everywhere, and I wouldn't count on an average car coming behind you being one.
I also concede that after measuring even my bike cannot do 100km/h in 10m, the initial speed travels distance too quickly, was about 35m to complete halt, couldn't brake harder if I tried, would have locked up the front wheel from the shocks being completely compressed.
Compared to the likely unreliable 'flashscience' website since they have an average car stopping distance calculator, while it's only like 20% shorter, that 20% shorter would still be enough to, on average, get your ass rear ended.
Of course it would be even worse for exotic sports cars, heavy braking would almost guarantee rear ending.
Check your information before you get in an accident.
I have stopped on my bike from 80 to stopped in less length than the width of a single driveway (bout 7m) will try 100km/h next time, if I'm off I doubt it would be by too much
Bikes have a LOT less inertia than cars, wind resistance helps a lot to slow you down when you go faster speeds than it does a car
In other words, the danger lies in your concentration not being on the road. If you're writing text, you're not concentrating on the road. Therefore I'd be surprised if texting didn't have similar risks.
If you're listening to the radio, your concentration is not on the road.
If you're talking to a passenger, your concentration is not on the road.
If you are looking at your GPS, your concentration is not on the road.
If you are adjusting your car mirrors for better view, your concentration is not on the road
I will stop talking on a handsfree (which is legal here anyway) when these other more distracting activities are outlawed.
I don't think the Linux development practices lend well to the range of hardware support Windows has, even if it were as popular.
Wait a second.. you do realize out of the box linux supports easily 50x the hardware windows does right? and support for hardware doesn't just magically disappear when the next version comes out either
Slashdot Mirror
Are you honestly trying to suggest that double clicking an install file or dragging and dropping an install file is somehow only easier than the mess of configure/make/compile simply because it is familiar? Really? Now you're just not being intellectually honest.
Let's see, typical usage, (using rpm based system), say I want blah, yum install *blah* -y however long after it downloads and installs for me later, I have it, could have done anything I want in the mean time while it was doing it's thing.
windows, i have to hunt it down on google, download it, then when I remember that I downloaded it, initialize the install process myself as opposed to having it automated..
for one or two things, this isn't so bad... getting windows from fresh install to a usable state by doing that though, is painful and time consuming.
General rule of thumb, these days you only have to compile yourself if you're doing some kind of fun mad science (with me it's usually making cross-compilers for strange architectures)
While I'm a very atypical case, I am used to configure/make/install routine, and I recently used a mac, the click and drag interface was so foreign to me the first time I was waiting there thinking it was just thinking about installing.
Also, in regards to security, any popular project will have quite a few people studying it's source, it only takes one of those to notice a problem (as you said, spyware etc) to notify everyone else where it will promptly be resolved... but, this never happens because any malicious changes are immediately noticed in the changelogs of the revision control software. Everyone monitoring each other keeps people honest, you can't do that in closed source software.
People spend years getting a reputation being a good coder, few are willing to lose that simply to get a little cash. When they will be caught sooner or later.
e.g. rt2500 -- there are open source drivers available, but you have to download them, compile them and install them yourself; the lack of a stable ABI makes the process difficult and time consuming, putting it beyond the scope of an average user).
I have an rt2500 based one and it works fine, didn't until about six months ago when the drivers went mainline, but anyway back to the main point
you seem to have missed the point, certification would be great, but a stable ABI is not needed for it.
Do you really think that magically every piece of hardware work would if we had a stable kernel ABI? there would still be lots of hardware not supported, even with a certification ("blah works on linux") program that would still be the case but at least you could tell what is and isn't supported before you purchase it.
The general idea with this isn't "get everything working" it's "let people know what will and won't work".
As you've said currently when you buy a piece of hardware you can never be sure what chipset etc you're getting or whether it will work. Add in some manner of linux tag where you can only add it to the product if the mainline kernel detects and uses it, and you would know what will or won't work out of the box, changing to an unsupported chipset would be grounds for removal of the use of the tag, make sense?
All of this would allow people to identify what works, and what doesn't, without a stable ABI, the reasons the ABI isn't stable are technical ones, I see no reason to gimp the linux kernel at the request of people who are not part of it's main development.
Package management is wonderful, but we need to standardize the damn things. I vote for Apt-RPM. Choice is good and wonderful, but not when it is considering package formats. Just pick one so we can finally just post a "Linux" binary on the web that works with every package management system seamlessly. How kick ass would that be?
Even if you only had one format, it would not work that way, each package in a repository is connected to dependencies on others, all of which could be compiled with support or non-support for specific libraries etc. You still would not be able to put one package there and have it be supported by all in all cases. Each package as it's added is tested to make sure it functions with the other packages in the repository.
What you said though, seems to be the only reason people want to have one package manager to rule them all. When it is false, what other advantages besides trivial ones would only having one package manager out there have?
Audio is a mess, and Pusleaudio is not the band-aid that will cure it; at least not in the state it is in. It doesn't help that distros can't package it correctly, but there are too many switches and levels for even the most simple of tasks.
See here we have different tools for different levels of functionality, according to you pulseaudio has too many switches and levels etc, well, pulseaudio is useless for anyone doing anything remotely serious with audio, way too much latency, jack is pretty much the only game in town so far as that is concerned, and it functions wonderfully, but would introduce even more complexity because of the flexibility it has.
Many things can get resolved over time, but conflicts of design goals are one of those things that do lead to different applications because of different needs. Pulse-audio seems to be trying to be everything to everyone, and failing horribly in the process for most, but working good enough for those who don't care.
a stable ABI is not equal to a certification program, which is more so what you would like.
Linux already has the largest in-built hardware support of any os, only as you correctly point out you won't know if it works until you try it. So why not test against a standard kernel and if it works give it the linux stamp you so want?
Because the vast majority of hardware manufacturers, especially in the home markets, are NEVER gonna give you their code. It simply isn't in their best interests and it opens them up to the risk of litigation by patent trolls
The card vendors no, the chipset manufacturers, the majority of them will give you specs if you demand them, why wouldn't they? the people purchasing the chipsets for use in cards need the specs to effectively use them. This is how most of the drivers in the linux kernel for random hardware is made, there are only a few notable hold-outs.
Having the drivers in kernel and frequently audited and updated is one of the linux kernels biggest strengths, running closed source random code in kernel mode from third parties is a serious security and stability risk. Most modern windows blue screens aren't caused by windows, but by shitty divers written by third parties.
Still, I think you should perhaps gather, that having a stable ABI will do sweet crap all in regards to linux driver uptake, and that what you really want is a linux hardware certification program, which would solve the peripheral problems you've mentioned, once a piece of hardware is supported in the linux kernel, that support is very very rarely removed.
Package management should be confined to a common package format.
I keep hearing this all the time from people, but they fail to see it as a non-issue. Repository packages have to test their requirements against the other packages and it's all an interconnected system for a given distribution. People seem to think 'if redhat went with .deb we could use fedora packages in debian without any fuss!!' not the case. And making packages for the different formats is trivial, and is done as you can see that there are pre-packaged forms of most poplar software for all the major distros.
As for sound, that is a more legitimate gripe however going back to OSS is not the way, OSS is way too limiting in it's capabilities, The pro audio sector pretty much dictates alsa + jack, but the 'desktop' crowd seem to be standardising on alsa + pulseaudio, which has so much latency it isn't funny, not to mention unable to do half the things jack can in regards to dealing with audio streams
Which is why i have said time and time again there needs to be a stable ABI and a "Tux the penguin" certification process.
Certification process fair enough, but a stable ABI is not needed for that, any piece of hardware that has a recognized in kernel tree driver driver should simply be plugged in and see if it works, if it does without any real issues, certification can be done
Trusting random companies with ring 0 privileged code your machine is a big leap of faith when you can't see the code, almost all of the bsod's you see these days on windows aren't microsoft's fault at all, but the fault of shitty drivers by third party companies. Some of us like the quality ensured by having in kernel frequently audited drivers
But still, allowing binary blobs is not needed for certification that *blah* works on linux. Linux does have the largest in-built hardware support of any modern os.
I'm using the Adobe flash plugin and fullscreen flash video plays smoothly for me.
seconded, using fedora, after reading the xkcd comic the first time I tested and there was no issue.
At the end of the day, the people that produced the content should be entitled to reap any benefits from it.
Just how will they reap the benefits of it 75 years after they are dead?
Its not like artists are actively prevented from creating content.
But.. they are, if practically eternal copyright had existed before, disney would not have been able to make most of it's movies. Just as people today cannot take those stories and be creative with them making their own adaptations.
This may surprise you, but very little of what we make is actually new, it is merely different combinations of already existing ideas, when you disallow the partial use of existing ideas, you are stifling creativity.
The idea of copyright is to give people incentive to create new works, what incentive is there to create new works when you can sit on already completed works for longer than a lifetime?
So you do see it there. Why do you think that the hardware is moot?
Why do you think hardware matters, when we are talking about software?
So, leaving aside the "but we know how to do that" argument, what's not patentable about the above when explicitly performed by a specific computing device?
So.. you are going to patent something on x86, have a separate patent for arm, separate patent for MIPS, for doing the exact same thing mathematically just expressed in a different language, for a different hardware chipset, are you? I highly doubt it.
example using Seti@home on your ps3 is not a novel and new idea compared with doing it on x86, it's just the same thing on different hardware. And even doign it on x86 isn't being novel, it's just doing maths on something that is designed to do maths.
I fail to see how doing maths on computers changes the fact it's just doing maths, just as I fail to see how doing maths on an abacus is not just doing maths (if the abacus were invented in modern times, it would have been patentable also)
if I had a board game, now this board game did something awesome, and was somehow patentable, and I figured out a fool proof way of playing this board game using maths, making instructions on how to, to you would those instructions be patentable?
That is your argument, that instructions to use something specific are patentable, I have no doubts this will not change your opinion, but it may make you think about what you are proposing a bit more.
No, I think that math that is actually expressed in an instruction set and explicitly requires the processors, memory and circuits that you admit are patentable is also patentable.
You just said no, then essentially repeated what I said in agreement... odd, you just said that you think maths that is expressed in an instruction set is patentable. The only addition being it MUST be tied to the hardware, You don't seem to get that the instruction set is moot, it's merely a language to express the maths in. Also randomly, I can read x86 hex code(slowly).. does that make me a computer and patentable? (/sarcasm)
so, you really don't see the difference between hardware and software running on that hardware do you? (also, the hardware could only be patented if they did something funky and new, most likely something in the way it was constructed or some such)
what you described in your example would never be accepted as a patent, it would basically cover the storing of anything in memory which computations could be done on, too vague, and it wouldn't even be patenting the software, just patenting a method of loading and executing software.
When it comes down to it, when you patent software, you are patenting maths behind the function of the thing that is being patented, or if the patent holder is really lucky, even the idea that something can be done (example, 1 click purchasing patent).
Jesus, I don't know where to start
It's not mathematics, because maths and logic don't contain circuits, processors, and memory.
Yes, maths does not contain those things, and ways of implementing processors, memory etc ARE patentable, and should be, this aspect has.. what to do with software?
Software does not contain circuits, processors, or memory, it may need them to run but it does not contain them. Software itself is a set of bits that tells a set of hardware what logical and mathematical operations to do. Which, mind you, is already covered under copyright.
Patents are about implementations of ideas, how are ideas implemented in software on a computer? through mathematics and logical operations.
You seem to think that just because the maths is expressed in an instruction set that hardware can decode and execute, that the maths should be patentable, I respectfully disagree./p.
In essence you are arguing that a words definition comes from common usage.
After listening to some of the tripe that comes out of teenagers mouths these days one would wonder if you could say that again with a straight face afterwards.
In regards to the term 'hacker' almost everyone who works in the industry to some extent knows the geeks version. Only those that don't have exposure get it incorrect, but most lay people don't understand trade-specific terms anyway. Does that mean that the people who study the trade are wrong, and the average person is right? due to their collective lack of knowledge?
In terms of software, while it used to be really bad, I think US patent law is moving in the right direction -- it looks like ultimately they'll allow software patents, but they're going to have to be a *lot* less general and a *lot* more in depth. Which is a good thing.
Interesting, what is your stance on the patenting of mathematics then? since all computer programs essentially come down to maths and logic.
Mass effect may be a decent game, but baldurs gate 1 and 2 are considered by many to be the gold standard of rpgs, the attention to detail and quality in them is pretty darn hard to equal, let alone surpass.
so wait a second.. you are saying when everyone else follows the normal standard, and apple does the weird and strange thing with custom parts, that everyone else should follow suit?
here's an idea, get a stereo (or make an adapter to the amp) that allows a standard 3.5mm stereo plug. It was your choice to limit your cars stereo to interfacing with an ipod by getting one with an ipod connector as opposed to something more.. mainstream
I know what you're talking about: Rudolph's dumper.
I used an original gameboy advance media player, with modified firmware, and I had not heard of rudolf's dumper until you mentioned it then, I had a tool around 2005'ish that could dump ds firmware, ds slot sram, and ds slot rom, very handy multi-functional tool, featured a debugger also. Cannot for the life of me remember the name of it but if I can remember I will post in a reply.
Any ideas on how to build an NES copier?
best bet to follow petermgreen's advice, my main experience is snes where we don't have memory mappers, just silly co-processors in cartridges :)
There are at least a dozen different ways to make cartridge based games self destruct their data if they're opened. You can't get the ROM off it if a system wipes it any time oxygen is sensed inside the cartridge which has a vacuum in it.
sure you can, I can dump my legitimate games onto cf card using my actual ds.. you do realize that for the cartridge to be usable the system has to be able to read the data... right?
dumping does not involve removing cartridge chips these days (ok.. well... arcade games sometimes) it either involves putting the cartridge into an original system that's running a dumper program, or making something yourself that has a cartridge port that can read it.
First, $600 is not going to buy you production 24/7 server quality machine that Mac Pro is.
quite likely, but $1500 will, that's still 1/3 of the cost, granted that neither the mac pro or that machine would be 'server' class, but they would be very similar in performance
For a serious, quality server, hot pluggable storage,redundant hot pluggable power supplies and cpu's are a requirement. Pluggable storage and power is frequently covered by many $6-8k rack mount systems (including x-serve) but hot pluggable cpu's will cost you, only IBM and SUN systems really do that, and they are pricey.
If you really want to use it to the fullest you have to install Windows 64 bit on it.
being on slashdot, you would of had to have heard of linux yes?
fully decked out mac pro (just added hardware bits on their customize section AU country though) comes to $26,199 AU (around $22,100 USD) for that much cash I'd be expecting a shit-tonne better system.
Base mac pro here is $4.5k with one quad core processor. 3gb ram, etc, still a nice machine, but you can make something better for about a grand and a half, and flickiestrife's $600 machine is better than it (includes a monitor even).
also, this is military stuff, armies like their independence from foreign nations, even if they are allies.
FJR1300 is more of a fast touring bike than sports, and upon checking weigh's 295kg, more than double the weight of mine.
here's another non-sports bike that does 100km/h-0 in 44m it's also a bit of a heavy machine though in comparison.
guess my bike is a bit odd in that the weight is extremely low to the ground in comparison to other bikes, thusly I can brake harder before the rear end lifts, as well as I have somewhat.. large front and rear tyres for the weight of the bike
I do completely agree that a sports car will out brake a motorcycle, but most people don't drive sports cars around the place everywhere, and I wouldn't count on an average car coming behind you being one.
I also concede that after measuring even my bike cannot do 100km/h in 10m, the initial speed travels distance too quickly, was about 35m to complete halt, couldn't brake harder if I tried, would have locked up the front wheel from the shocks being completely compressed.
Compared to the likely unreliable 'flashscience' website since they have an average car stopping distance calculator, while it's only like 20% shorter, that 20% shorter would still be enough to, on average, get your ass rear ended.
Of course it would be even worse for exotic sports cars, heavy braking would almost guarantee rear ending.
Check your information before you get in an accident.
I have stopped on my bike from 80 to stopped in less length than the width of a single driveway (bout 7m) will try 100km/h next time, if I'm off I doubt it would be by too much
Bikes have a LOT less inertia than cars, wind resistance helps a lot to slow you down when you go faster speeds than it does a car
In other words, the danger lies in your concentration not being on the road. If you're writing text, you're not concentrating on the road. Therefore I'd be surprised if texting didn't have similar risks.
If you're listening to the radio, your concentration is not on the road.
If you're talking to a passenger, your concentration is not on the road.
If you are looking at your GPS, your concentration is not on the road.
If you are adjusting your car mirrors for better view, your concentration is not on the road
I will stop talking on a handsfree (which is legal here anyway) when these other more distracting activities are outlawed.
I don't think the Linux development practices lend well to the range of hardware support Windows has, even if it were as popular.
Wait a second.. you do realize out of the box linux supports easily 50x the hardware windows does right? and support for hardware doesn't just magically disappear when the next version comes out either
the handsfree example is essentially the same as having a passenger speak to you, should that be banned also?