Is there some kind of automated mechanism to digitize books and magazines without a ton of manual effort? I used a flatbed scanner to scan quite a few magazines, and while this worked excellently in terms of the output, I have far more printed material than I would ever have time to digitize in this manner.
To be fair, there is an association with VIA and poor stability in some people's minds because of two reasons: one, the Windows support is quite a bit worse than the Linux support, necessitating arcane workarounds in some areas (not that Intel or AMD chipsets haven't suffered from the same from time to time), and secondly, the same Taiwanese and Chinese vendors who tend to use VIA chipsets also tend to buy the cheapest capacitors they can get. I can't tell you how many times I've been presented with or given a VIA board that "went bad" or "has an unstable VIA chipset" and a bunch of the caps were either leaking or turned up with high ESR.
No one wants to spend time writing a new sound library that actually works when they can just look down their noses at anyone who doesn't know how to properly configure ALSA.
I really don't see the point of all this bleating. ALSA is configured for software mixing by default, and it's your distro's fault if they don't ship with such a configuration. There is none of this elitism or zealotry that you are attempting to cast upon the ALSA project. Patches are readily accepted if they do the job and fit within the design.
All sound cards and integrated sound chipsets have had hardware mixing for the last 10 years.
You're completely wrong. Not only does this statement not reflect the situation, it's actually getting worse. The trend now is to *remove* hardware mixing even from brands and product lines which previously had it. Just check the ALSA mailing list for gripes about this if you don't believe me. It is a combination of people buying the lowest priced sound card they can afford, Windows having a kernel software mixer since Windows 98, and CPUs being so ridiculously fast that software mixing is no longer a significant resource drain. Hardware mixing adds cost to the design and doesn't sell any more cards, so it is axed from today's designs except at the professional high end.
The ALSA audio API was not designed for developing simple applications. If you want a simple API for apps, look at PortAudio, SDL, Jack, or any of the other abstraction layers that were designed to do what you want.
Remember, a PC today is still based on the design of an XT. You've got bizarre things such as the 20th bit of the CPU addressing being disabled at boot time. Multiple interrupt controllers and DMA controllers cascaded off each other. You reboot a PC by sending a signal to the keyboard controller.
Your gripe about A20 is valid, since there is no way to create an A20 routine which will operate on all machines. Also, resetting a machine through the KBC may be kludgey, but at least it works every time. (You could instead transition back to real mode and jump to the firmware segment after disabling interrupts.) Your other points are mostly irrelevant now. With newer motherboards with IO-APICs, there is no longer a need for multiple interrupt controllers. With PCI, there is no need for the 8237 DMA controller either - PCI has integrated busmastering DMA.
For example, just a few notes taken from one song and used in another has resulted in liability.
And to me, this is the limit of absurdity. Just because things are this way, doesn't mean they *should* be this way. Do you honestly not see a chilling effect on new development here? There are twelve tones in the musical scale and four subdivided beats in the typical measure. How long can you create music before one of your concocted measures happens to match one of somebody else's that is still under copyright, especially given that copyright terms are on the order of centuries now?
Remember how I said that it wasn't a good idea to try to be clever? The infringement in your example is perfectly obvious, and no court is going to be stupid enough to not see it.
It may be obvious that infringement is occurring, but you have not convinced me that the downloader is the one who is making the copy. Without the structural information provided by the others who have the file themselves, the infringement would not have been possible. That makes them an enabling factor and thus a contributor at least. But then why are people who operate warez FTP servers considered infringing themselves and the downloaders contributors? By your argument, it would be just as reasonable to conclude that the downloader invoked the copy and thus is responsible for the work's unauthorized reproduction. The FTP server is the enabler, and the downloader is the causal factor. In this case, the FTP server can be viewed in two ways: either as an enabler or as creating an unauthorized production itself on the operator's end when it makes a copy for transmission.
Well, your first mistake is to be examining the generated configure script instead of the macro files it is generated from (configure.in or configure.ac). I don't particularly like autoconf, but it's not *that* bad!
I don't see a valid reason outside of not being standardized (yet) that strlcpy/strlcat are not included. They are both faster and more reliable than their 'n' counterparts. If they were included as extensions, this would certainly encourage them to become part of the C standard.
It's interesting that the example you cite as being particular nasty for autoconf to support (Digital UNIX) is also one of the last that would ever adopt your scheme of making the operating system partially responsible for autoconf. If such an initiative were to succeed, it would succeed only among the free operating systems, that is, if you could get any of them to agree that helping propagate autoconf or anything like it is a good idea.
To what limit? How about if each sharer offers just one paragraph? A sentence? A word? A letter? If each sharer provides one letter and its index in the final assembled file, where is the copyright violation being committed?
I think this ruling is just inviting more legislation to "clarify" the use of BitTorrent and similar technology as copyright violations.
Yes, that would be nice, *if* you knew about it before investing a half million dollars into developing your game only to be hit with an injunction as soon as it ships.
Allowing people to patent everything in sight is going to increase patent submissions and lawsuits, and generally have a chilling effect beyond that. There's no way to afford an exhaustive patent search on every function point of your project, so it's easier to just do something else.
The word "suspect" is much better than the word "believe" when we are talking about things that we have no evidence either for or against. "Believe" connotates that the claim has been accepted pending contradictory evidence, even with a lack of supporting evidence; "suspect" or "doubt" conveys what the person's intuition tells them (which is what we are aiming for here) while not implicitly accepting something that may well be false.
DPMI? Perhaps you meant DPMS? Console DPMS is not hard-wired, you can easily enable and disable it from userland. For example, the X server disables it so that it can manage DPMS itself.
Meanwhile on X, we're still hand-editing x86config files and guessing what the optimum scan parameters should be.
If your monitor sends EDID info over DDC like any monitor built in the last 15 years, X -configure will save you a lot of pain, if you're still living in the Unix of the 80's as it seems.
Yes, because both printers happen have a hardware printer language and support the same language (PCL6 likely). Now try that with a non-HP consumer inkjet and see how far you get.
Slashdot Mirror
Is there some kind of automated mechanism to digitize books and magazines without a ton of manual effort? I used a flatbed scanner to scan quite a few magazines, and while this worked excellently in terms of the output, I have far more printed material than I would ever have time to digitize in this manner.
To be fair, there is an association with VIA and poor stability in some people's minds because of two reasons: one, the Windows support is quite a bit worse than the Linux support, necessitating arcane workarounds in some areas (not that Intel or AMD chipsets haven't suffered from the same from time to time), and secondly, the same Taiwanese and Chinese vendors who tend to use VIA chipsets also tend to buy the cheapest capacitors they can get. I can't tell you how many times I've been presented with or given a VIA board that "went bad" or "has an unstable VIA chipset" and a bunch of the caps were either leaking or turned up with high ESR.
The ALSA audio API was not designed for developing simple applications. If you want a simple API for apps, look at PortAudio, SDL, Jack, or any of the other abstraction layers that were designed to do what you want.
I'm going to build a computer where the individual components are mounted on the blades of a giant fan. How much better air flow could you get?
Well, your first mistake is to be examining the generated configure script instead of the macro files it is generated from (configure.in or configure.ac). I don't particularly like autoconf, but it's not *that* bad!
Um, irony is a type of sarcasm. Sorry.
I don't see a valid reason outside of not being standardized (yet) that strlcpy/strlcat are not included. They are both faster and more reliable than their 'n' counterparts. If they were included as extensions, this would certainly encourage them to become part of the C standard.
I fail to see how only allowing OS X to run on Apple systems precludes the development of poorly designed third-party hardware and software.
It's interesting that the example you cite as being particular nasty for autoconf to support (Digital UNIX) is also one of the last that would ever adopt your scheme of making the operating system partially responsible for autoconf. If such an initiative were to succeed, it would succeed only among the free operating systems, that is, if you could get any of them to agree that helping propagate autoconf or anything like it is a good idea.
That's why you swap the guts and return the same shell that you bought.
I think this ruling is just inviting more legislation to "clarify" the use of BitTorrent and similar technology as copyright violations.
They are talking about eating the CPU. You're talking about eating memory. Two completely different issues.
Unfortunately, -586 and -k6 kernels have been phased out. A rather unfortunate move for us since my laptops are -586 and three servers are -k6.
And don't even think about touching the power supply until you've discharged it as well or waited for it to drain off. That capacitor WILL kill you.
Yes, that would be nice, *if* you knew about it before investing a half million dollars into developing your game only to be hit with an injunction as soon as it ships. Allowing people to patent everything in sight is going to increase patent submissions and lawsuits, and generally have a chilling effect beyond that. There's no way to afford an exhaustive patent search on every function point of your project, so it's easier to just do something else.
The word "suspect" is much better than the word "believe" when we are talking about things that we have no evidence either for or against. "Believe" connotates that the claim has been accepted pending contradictory evidence, even with a lack of supporting evidence; "suspect" or "doubt" conveys what the person's intuition tells them (which is what we are aiming for here) while not implicitly accepting something that may well be false.
DPMI? Perhaps you meant DPMS? Console DPMS is not hard-wired, you can easily enable and disable it from userland. For example, the X server disables it so that it can manage DPMS itself.
Yes, because both printers happen have a hardware printer language and support the same language (PCL6 likely). Now try that with a non-HP consumer inkjet and see how far you get.
There's no driver for the system board. It's listed there because Plug&Play enumerates it and reserves resources for it.