Are you taking vitamin supplements? I've heard of this and most people chalk it up to a vitamin deficiency. You will be a little fuzzy during the day if you are a regular stoner, (you would be if you got drunk every day too). If you aren't sure of the permanence, lay off the weed entirely for a month or two (the time it takes for the cannabinoids to be completely metabolized and cleared from your system) and see if the condition improves. Of course, by that time you may be used to your present condition enough to not know what it used to be like...
Something else you might think about is whether those experiences changed your thought process not by altering your brain chemistry in any way except through the learned experience. For example, I know that my connection with my senses was strengthened quite a bit from getting high on a regular basis, because I became aware of things that my senses were picking up but that I was ignoring. Then I could apply that knowledge to non-high experiences, resulting in a "different" approach to life using that knowledge. I don't know if that makes any sense or not. I think what I'm trying to say is that any experience will change you to one extent or another, and getting high for the first time is one of the most profound of experiences. So I wouldn't worry too much about being "damaged" and simply adjust back, and if you feel weed is getting in the way of your goals, quit.
This should help you complete your list. Note that JTS actually purchased the remains of Atari, then sold them to Hasbro before going bankrupt. (Did JTS stand for Jack Tramiel Systems by any chance?)
However, there are some models that can be identified as suffering from faulty engineering or manufacturing. Maxtor and WD GLIST issue comes to mind, as do the IBM GXP series. These drives do fail in considerately greater numbers than the average, and it is sound advice - not dogma - to avoid them.
Printing can be interrupt driven, since printers are connected via parallel, serial, or USB ports, all of which are capable of generating interrupts. I don't think I've ever encountered a parallel port printer that was incapable of interrupt driven operation, for example, and the Linux kernel printer driver has taken advantage of it (I don't know about Windows).
Re:Does not higher density mean higher risk?
on
Hard Drive Window
·
· Score: 1
I have opened many hard drives and never had to remove a cover screw that affected anything besides the cover itself. Can you cite a particular model please?
Re:I've run a naked drive for a week
on
Hard Drive Window
·
· Score: 1
Yes, and then what happens when the spare sector pool runs out? IOW, you're full of shit. Sorry. I have handled MANY drives with so many bad sectors that the spare pool was exhausted and they spilled over to be host-visible.
They are about incentivizing the publication of new ideas.
No, they are about inventions, not ideas. And given the premises of the article, one of which is that these publications are frequently devoid of any technical value due to lax examination and broad interpretation, your argument doesn't amount to much. Many patents might as well have not been published at all since the public is receiving nothing of value in exchange for the temporary monopoly.
No, let's not throw out the baby with the bathwater, but let's also not pretend that everything is fine. Overly broad patents benefit the creator, at the expense of creating a market inefficiency which should be paid back by enriching public knowledge, but is not.
Already such a thing exists, it is called UDI. It was summarily rejected by the kernel folks for several reasons. First, it doesn't really solve any political problems associated with getting drivers ported for products that are already released. Instead of porting your driver to Linux, you have to port it to a different interface. It only would help in the case of new products.
Unfortunately, maybe it is the kind of help we don't want, because such a driver would be slow. To some people, this makes the vendor look bad, but to others, this makes Linux look bad. And it is unavoidable that a portable driver interface would slow things down. The problem is that you have to capture not only existing functionality, but also existing developmental approaches that are completely different from platform to platform. By that, I mean that different operating systems are designed to prioritize different types of usage and methodologies, so when we go to create a "Universal" driver interface, we have two things to balance - the level of abstraction from the OS and the performance of the driver, inversely proportional. Since fast performance on Windows is a market necessity these days, a driver abstraction layer just isn't going to get any attention.
I have been led to believe, through examination of commercial open source drivers as well as proprietary drivers that are subsequently open sourced, that vendors who want to support multiple operating systems design their own hardware abstraction layer, and that this layer is typically specifically for the product in question. It suggests that creating a portable driver framework from scratch really isn't that big a deal, in which case developers can create that framework with full knowledge of the hardware and specifically to take advantage of the hardware's design, instead of using a "universal" layer designed by people who have never seen your hardware and your users' requirements. I'm just not sure that a UDI-type thing being available is all of a significant time-saver for driver developers, especially when it has performance ramifications for the end user that may affect their perception of the product negatively.
What's even more ridiculous about it is that so-called "emotional damage" is largely under the control of the person claiming it. They choose to be offended by something. They choose to let it bother them, to consume their thoughts, to let it control their disposition. Without an objective basis for what constitutes emotional damage, the claims are limitless. And this encourages people to be weak and easily offended, since the weaker and more neurotic you are, the more emotional damage you can claim, and the more you profit - thus reinforcing that behavior and outlook both in yourself and in observers. Sigh.
I bought a RT2500 card. Immediately after buying it, I emailed RALink's sales team and gave them the reasons why I chose their product, one of which included company-supported open source drivers. If only everyone would do the same when buying their hardware...
OpenGL already does that. Unfortunately, there doesn't seem to be a way to detect functionality that is supported in hardware apart from manually profiling the GL driver. As a result, you get software fallbacks in many cases where you just wouldn't have bothered rendering had you known it'd be in software. User configuration options can mitigate this somewhat.
The crux of the problem is the OpenGL ideal - that a hardware accelerated OpenGL application and a software rendered one will be identical in their output, transparent to the user and the programmer. In general, this is great. But it would be nice to have a well-defined escape path for cases where you would in fact want to throw away quality for speed.
When an inventor has to search for patents when designing every portion of a capital work
... and when an inventor is actually worse off for having searched for the patent, in that he is now liable for willful infringement if he continues to sell his product...
There needs to be a self-contained package format like OS X's.app bundles. No using a program to install a program or a program to uninstall a program. Just copy it to install it or delete it to uninstall it.
And just like that, back we go to the age of needing a virus scanner on every box to detect executables that have been infected by user-propagated exploits. No thanks - I prefer my system-wide executables at a higher-than-user modification permission.
Not that you should be prevented from doing what you want to do, but it's such a bad idea that it has a quite low priority among those actually doing the developing.
Not having separate -dev packages is a HUGE pain in the ass for embedded and other space-constrained systems where you wouldn't even think of putting a compiler, much less build libraries.
Apparently you have never heard of PAM. Like it or lump it, but that's the reason behind not building a bunch of crazy authentication options into every package. Kerberos is an exception because it doesn't fit nicely into the PAM model (e.g. for TGT forwarding). For the rest of stuff you are complaining about, PAM has suited me fine. A LDAP database stores account information, and pam_ldap is used to pull it for any service by entering it in common-account and common-session. I have never had to manually recompile any LDAP related package nor any service that uses LDAP.
Don't give up hope, RiscOS! You're this close to following AmigaOS's meteoric rise to desktop dominance. Don't loosen your death grip on that code base! Amiga didn't, and now they're poised to overtake Windows any month now. Remember, sharing your code is admitting defeat. Why go the way of the dodo when you can shine in the spotlight like Amiga!
In other news, the Flat Earth Society, after being essentially ignored for years as "obsolete", has finally made great strides towards getting schools to acknowledge the truth that we've known all along in their science textbooks. Hopefully they won't stop now while they've got momentum going....
Yes it does. A filesystem is a part of the kernel. The kernel is under the BSD license. The inclusion of Reiserfs code in the kernel would require it to be under the GPL license instead
Fine. So "porting this filesystem to BSD" now includes "reimplementing the kernel filesystem driver". That is not an impossible task and was already done with several drivers.
Having to build custom packages is *precisely* what I want to avoid. To be honest, in more than 10 years of Unix/Linux/BSD use, the only situations where I wanted/needed to build custom packages occurred with Debian:
However, if you were a distribution maintainer, as the GP is, your tune would change. You know, users kind of like binary packages. Especially those ones that don't have 2GB and several days to build Xorg and friends.
Slashdot Mirror
Something else you might think about is whether those experiences changed your thought process not by altering your brain chemistry in any way except through the learned experience. For example, I know that my connection with my senses was strengthened quite a bit from getting high on a regular basis, because I became aware of things that my senses were picking up but that I was ignoring. Then I could apply that knowledge to non-high experiences, resulting in a "different" approach to life using that knowledge. I don't know if that makes any sense or not. I think what I'm trying to say is that any experience will change you to one extent or another, and getting high for the first time is one of the most profound of experiences. So I wouldn't worry too much about being "damaged" and simply adjust back, and if you feel weed is getting in the way of your goals, quit.
Is the Bible, or is it not, the infallible, divinely inspired word of God?
Erm yes, the heads and platters expand with heat, but there is still a layer of air that the head rides on, no matter how much the platter expands....
This should help you complete your list. Note that JTS actually purchased the remains of Atari, then sold them to Hasbro before going bankrupt. (Did JTS stand for Jack Tramiel Systems by any chance?)
Micropolis went bankrupt in 1997.
However, there are some models that can be identified as suffering from faulty engineering or manufacturing. Maxtor and WD GLIST issue comes to mind, as do the IBM GXP series. These drives do fail in considerately greater numbers than the average, and it is sound advice - not dogma - to avoid them.
Yeah, until xdm spawned a new X server to replace the one you killed?
Printing can be interrupt driven, since printers are connected via parallel, serial, or USB ports, all of which are capable of generating interrupts. I don't think I've ever encountered a parallel port printer that was incapable of interrupt driven operation, for example, and the Linux kernel printer driver has taken advantage of it (I don't know about Windows).
I have opened many hard drives and never had to remove a cover screw that affected anything besides the cover itself. Can you cite a particular model please?
Yes, and then what happens when the spare sector pool runs out? IOW, you're full of shit. Sorry. I have handled MANY drives with so many bad sectors that the spare pool was exhausted and they spilled over to be host-visible.
No, let's not throw out the baby with the bathwater, but let's also not pretend that everything is fine. Overly broad patents benefit the creator, at the expense of creating a market inefficiency which should be paid back by enriching public knowledge, but is not.
Because marijuana is a dangerous drug that invokes paranoia, madness and criminal behavior in everyone who does not use it.
Unfortunately, maybe it is the kind of help we don't want, because such a driver would be slow. To some people, this makes the vendor look bad, but to others, this makes Linux look bad. And it is unavoidable that a portable driver interface would slow things down. The problem is that you have to capture not only existing functionality, but also existing developmental approaches that are completely different from platform to platform. By that, I mean that different operating systems are designed to prioritize different types of usage and methodologies, so when we go to create a "Universal" driver interface, we have two things to balance - the level of abstraction from the OS and the performance of the driver, inversely proportional. Since fast performance on Windows is a market necessity these days, a driver abstraction layer just isn't going to get any attention.
I have been led to believe, through examination of commercial open source drivers as well as proprietary drivers that are subsequently open sourced, that vendors who want to support multiple operating systems design their own hardware abstraction layer, and that this layer is typically specifically for the product in question. It suggests that creating a portable driver framework from scratch really isn't that big a deal, in which case developers can create that framework with full knowledge of the hardware and specifically to take advantage of the hardware's design, instead of using a "universal" layer designed by people who have never seen your hardware and your users' requirements. I'm just not sure that a UDI-type thing being available is all of a significant time-saver for driver developers, especially when it has performance ramifications for the end user that may affect their perception of the product negatively.
What's even more ridiculous about it is that so-called "emotional damage" is largely under the control of the person claiming it. They choose to be offended by something. They choose to let it bother them, to consume their thoughts, to let it control their disposition. Without an objective basis for what constitutes emotional damage, the claims are limitless. And this encourages people to be weak and easily offended, since the weaker and more neurotic you are, the more emotional damage you can claim, and the more you profit - thus reinforcing that behavior and outlook both in yourself and in observers. Sigh.
I bought a RT2500 card. Immediately after buying it, I emailed RALink's sales team and gave them the reasons why I chose their product, one of which included company-supported open source drivers. If only everyone would do the same when buying their hardware...
The crux of the problem is the OpenGL ideal - that a hardware accelerated OpenGL application and a software rendered one will be identical in their output, transparent to the user and the programmer. In general, this is great. But it would be nice to have a well-defined escape path for cases where you would in fact want to throw away quality for speed.
Many 3D cards, even ones currently being sold at the low end, do not have shader support or a programmable pipeline at all.
Not that you should be prevented from doing what you want to do, but it's such a bad idea that it has a quite low priority among those actually doing the developing.
Not having separate -dev packages is a HUGE pain in the ass for embedded and other space-constrained systems where you wouldn't even think of putting a compiler, much less build libraries.
Apparently you have never heard of PAM. Like it or lump it, but that's the reason behind not building a bunch of crazy authentication options into every package. Kerberos is an exception because it doesn't fit nicely into the PAM model (e.g. for TGT forwarding). For the rest of stuff you are complaining about, PAM has suited me fine. A LDAP database stores account information, and pam_ldap is used to pull it for any service by entering it in common-account and common-session. I have never had to manually recompile any LDAP related package nor any service that uses LDAP.
And setting your USE flags is not "editing a bunch of files"?