It wouldn't take a factory. You could probably build something like this by hand. You can get USB chipsets individually pretty cheaply, and I'd imagine the case is the same for Bluetooth.
I don't agree. From at least her standpoint, the reaction to her act was what was humiliating.
That doesn't mean that I don't find the father's reaction understandable. I'd probably be royally pissed off as well. But I also really think that if you have a kid that's old enough to have a cell phone, that kid should also be old enough to decide whether or not they're religious.
Think about this from her situation. My guess is that she didn't want to be there, and was more than willing to make a pain out of herself. She saw that as her only way to gain influence, since clearly she didn't have enough to get herself out of attending in the first place. Now, her father breaking her cell phone *might* have taught her a lesson -- I'm talking about a secondhand story without a lot of detail. However, I've found that generally, folks are more willing to learn if they're at least somewhat empathizing with the other folks. I could see her simply transferring her embarrassment about the phone and the situation to her father and the other people, and complaing about it to her friends. She shouldn't have pulled out the phone, but by way of teaching lessons, neither should be break valuables when he's upset or -- in my opinion -- have taken her to church in the first place if she clearly didn't want to come.
I've had university lecturers who, when a cell rings in their class, stop speaking and simply watch the person whose phone is ringing. Naturally, everyone else turns and looks too. There's no accusation, no sense of "those people are deliberately insulting me", but inevitably the red-faced student is mumbling apologies as they hurry to smack the hangup button.
Oh, I don't know. I really do dislike cell phones -- to the point where, if I could easily obtain and carry a portable jammer, I probably would -- but I just can't help but think that everyone in that church could have probably solved the problem in a kinder way. Heck, these are a group of people kneeling in a *Christian church*. Social issues ignored, what happened to "turn the other cheek"?
So, let's look at this for a moment. The RIAA is trying to standardize something with official meaning for mass electronic distribution. The RIAA is one of the few generally-disliked groups by geeks (even if you disapprove of filesharing, the RIAA hasn't taken the nicest steps in the past to deal with things). They're up there with the Church of Scientology.
I'm going to give even odds that as soon as the first one of these goes out, it'll get posted on the 'Net, and used as propagation fodder for the next Internet email worm (in place of, say, "I Love You") -- so instead of everyone deleting emails containing "I Love You" in the subject, they'll start deleting emails that look like copyright infringement warnings.
Unfortunately smoke grenades in such games are simulated far too poorly; a single smoke grenade should create larger, thicker clouds of smoke much more rapidly; and without microwave radar (requiring a non-man portable emmiter), a sniper cant see you through a cloud of smoke.
This is an incredibly true statement. Smoke as-used-to-obscure-enemy-player-view in video games sucks. A lot.
There are a bunch of problems involved. It's hard to make good-looking smoke without blowing a lot of cycles. The more smoke, the more cycles blown, since smoke's usually implemented as masses and masses of alpha-textured polygons.
The conventional ways of obscuring vision are generally in the form of setting the ambient color (many games do this underwater, and it doesn't work well unless everything is one color), screwing about with gamma levels (doesn't work well unless everything is one color, relatively easy to hack, especially since some video cards may not support gamma level setting), or masses and masses of polygons with a texture with a very high alpha value, which tends to beat up on one's video card.
I'm curious as to what one can do with pixel shaders (which I haven't played with) -- whether volumetric fogs can be approximated. If so, and with pixel shaders becoming more standard, it might be possible to implement a more hack-resistant vision-obscuring effect that looks better.
Although...some folks don't like being *killed* by sniper rifles. Anyone can get a little annoyed, but in 2fort5 in Team Fortress, the kind of snipers that surface are simply inhuman. Furthermore, snipers really *do* rack up insanely high kill ratings.
I'd be interested in seeing a reformed variant of a sniper. Basically, in real life, to the best of my knowledge, sniper rifles aren't used because they're significantly more deadly than another type of rifle. They're used because they're very accurate. I'd be interested in just having a very accurate version of the rifle, and other weapons have progressively higher introduced error.
Adding a scope/crosshairs is also a nice idea, but very vulnerable to hacking -- it's much easier to modify a client's game engine so that it has crosshairs or a high zoom than it is to muck with error, if properly implemented.
Another issue with snipers in games is that conventionally, snipers may be exposed if they try taking on hordes of armed people heading their way. To snag a concept from Snow Crash -- a water tower may make a really great place for a sniper to hang out, but it's also a nice, exposed area where people can shoot. So real life military snipers probably don't want to hang about there, even if they could kill a lot of people from there. In a game, the values are significantly different. People are *willing* to gamble their character's life on a lucrative position that may grant high kill count with no escape route.
Of course, now she has zero chance of willingly going to said church again. She was humiliated in front of everyone, a presumably expensive piece of hardware was broken, and she was whacked.
The easiest solution, methinks, would have been not dragging her to church if she didn't want to go. Trying to force church on the actively disliking is a waste of time and effort.
I find "snooze" as a whole stunningly useless. The whole concept is flawed -- it just treats your brain not to wake up when the alarm goes off, which makes your alarm clock ineffective.
I believe at least some of Europe generally uses 24 hour time (and damned intelligent too -- AFAI can tell, the only reason for 12 hour clocks are analog clocks). Perhaps a Euro-Slashdotter could clear me up on this.
Anyway, if this is the case, a European alarm clock should be 24-hour.
Of course, you might need a voltage adapter.
As a suggestion -- you might consider setting up your computer as an alarm clock. I did so for a while. There are some caveats to consider. If you ever mute your system or plug in headphones, you may end up inadvertently muting your alarm as well. I avoided this by using a Linux box with two soundcards -- one hooked up to the speakers that woke me up. This also let me implement my *other* alarm-clock-most-wanted-feature -- the ability to disable an alarm before it goes off. Nothing pisses me off more than waking up five minutes before my alarm goes off and having the choice of either sitting and waiting for it to go off so that I can flick it off and on again to reset it for the next day, or simply turning it off and hoping that I remember to re-enable it before going to sleep the next day. Very annoying. Oh, and I also had the thing set up to not ring on weekends. God, I hate alarm clocks waking me up on weekends. Perl can make your sleep experience much, much better.
Another feature that you might find useful is kicking the thing off after a minute. If I'm not up after a minute of beeping, I'm not getting up, and it's really annoying to have someone's alarm clock going off because they didn't clear it when away.
They don't really stop you faster than other methods, but they may allow you to steer away from your previous destination, something you could never do if your wheels are completely locked.
Actually, I believe that you are not correct. Maximum "Static" friction that one surface can exert on another is greater than the maximum of the other type (sorry, forget the name...been a while since physics) of friction, the type between moving surfaces. Pulsing the brakes approximates hitting the brakes as hard as you can without actually starting to slide, since static friction is playing a role.
I believe that ABS still (though this could be out of date) can be outdone in practice by a human very familiar with a car's characteristics and the surface they are driving on, like professional race car drivers, since they can very accurately judge the point at which they will begin to slide, and keep the brake just below that.
You know, I don't really care about the issue one way or another, but I do find it interesting that your source is Ford marketing videos, and the person you're arguing against is actually digging up objective, third party sources.
I see a *lot* of women that put their cell in a purse. Not only does this mean that the vibrate function is useless, but it means that when the audible rings start, they start fumbling around in their bag. Extremely annoying.
The GPL allows Manufacturer X to make software or drivers that are proprietary and not open-source for inclusion in a distro if said works don't include any GPL code? I'll take your word for it for now but will go back and re-read the salient sections of the GPL. I thought that was both legally and ethically forbidden.
Yup. Packaging GPLed and non-GPLed code together is allowed. (For instance, for many years, most Linux distros shipped the closed-source Netscape Communicator suite.) The restriction is on linking -- you may not link non-GPL code to GPL code. This applies to both static linking and dynamic linking. A software package could even have both closed-source and GPL components if the GPLed code was in its own daemon and was communicated with the non-GPL code through a pipe, rather than being linked to it.
I understood that too, but the "Law of Unforseen Circumstances" has a nasty way of jacknifing that reality.
Apple actually included DRM in their own products long before Palladium -- I believe that HFS+ still has (HFS certainly does) a "Copy Protected" flag. The flag has been deprecated for ages upon ages, but it's still in there. I believe it may have been officially deprecated with System 7, but it would take a bigger Apple filesystems guru than I to tell its story.
I would have thought that at *least* when they walk outside of the house into the public area, he'd have the right to video record them, simply because they're in public.
I'm also a little surprised that they were able to say that he couldn't take pictures.
Perhaps not. If I'm taking notes as I'm breaking into a network, and say that "10.31.4.15 IIS DNS vulnerable", that's certainly evidence.
On the other hand, frankly, while having a prescedent of breaking into networks is bad, even if he did it, I hope he gets off on a technicality. The Hungry Programmers have produced a lot of really good free software with huge amounts of their time and talent, benefiting society as a whole. Having them in the wild, instead of behind bars, helps everyone. Valve, on the other hand, has refused to support Linux, has dicked around on their latest release, and generally failed to do nearly as much to make *my* life, at least, better. I'm a lot less sympathetic to a random corporation in it for the money than I am towards really good open source programmers. Talk about "paying a debt to society" -- this guy's done enough to get out of a grand theft rap, in my book.
Plus, if he comes this close to being burned, it's a good bet that he won't be cracking again...
Can someone explain to me why we need to get linux running on every desktop in the world exactly??
To say it step-by-step:
1) Hackers like Linux more than Windows. It's a nice, powerful OS.
2) Microsoft sells Windows. It wants people to buy copies of Windows. One major weapon in its arsenal is compatibility --.doc files, for instance, are not easily readable on non-MS products. MS has significant incentive to deliberately attempt to introduce incompatibility.
3) Hackers are not islands. They must interact with other people. Sometimes this means getting DSL service. Sometimes this means having to use a computer specified by an employer. Sometimes this means being able to read.doc files. Since Microsoft is The Institution and tries to isolate itself from other efforts, hackers frequently have to put up with Microsoft's products, even if they do not want to use them.
4) Hackers, frusterated with Microsoft, happily work on Linux and other Microsoft-alternative efforts.
Linux having a 30% market share or more would have major benefits (well, and probably drawbacks as well):
* Hardware compatibility. Someone has to write drivers and test and support hardware. It's expensive, so usually this sort of thing is subsidized by lots of people. If many non-hackers are using Linux, then hackers will get hardware support subsidized by non-hackers. This is a Good Thing for them.
* Games. There needs to be a lot of folks willing to buy a game before a company will port, test, and support it on Linux. It's expensive, so usually this sort of thing is subsidized by lots of people. If many non-hackers are using Linux, then hackers will get games subsidized by non-hackers. This is a Good Thing for them.
* Enabling People. Hackers are human too, and they feel good when they let people do something more. It's rather like the digital artist that introduces a conventional photographer to Photoshop. When the photographer's eyes light up and he realizes what he can do, and his ability to produce value increases, the artist feels good, and has helped society. Linux has a number of capabilities that Windows does not, and introducing folks to them would help society.
* DRM. Lots of hackers are not thrilled with the concept of DRM. Establishing a less monopolistic platform rapidly makes it much more difficult for anyone to get everyone using DRM.
* Environment. I'd love to never have to use a Windows box again. However, I run into them. The more people using Linux, the more folks paying people to work on and develop things for Linux, and the less one has to support Windows machines.
* Elimination of proprietary protocols and formats. Only one person directly wins if a proprietary protocol or format is in place -- the vendor of the software using it. Consumers lose, and competitors lose. Linux, having a large collection of entrenched open source and open specification software packages, has a good amount of inertia to not having closed formats.
Now, I grant that there will probably be drawbacks to a dominant Linux. Whatever the dominant easy-to-use distro is, it will likely have security failings, may force people to use a GUI to configure things, and may have a vendor doing all kinds of licensing deals for exclusives (like Microsoft's AOL icon on the desktop). Trojans and viruses will likely be more common for Linux. Politics will become more involved with Linux, just as it did with the Internet (imagine the same thing happening to the FSF that did with ICANN -- being taken over by less-than-nice corporate interests. Ick.) There will be many packages ported, and some of the existing Linux software that appeals to hackers -- small, CLI programs that can easily be combined -- will lose relevance as folks use ported, large, potentially buggy software packages like MS Office. There will probably be more strict backwards compatibility constraints, and cruft will more easily bu
Part of the Linux/Unix fascination is a transformative mindset that confuses cryptic complexity with power and ease-of-use with restricted utility.
I find this terribly ironic, as I have frequently seen the similar sentence "Part of the reason people still use Windows is that they confuse restricted utility with ease-of-use.
More to the point, GUIs really only differ from CLIs in one major way -- they provide a list of your options at any given point, from which you select one. They are very similar to menu-based text interfaces, abeit with a higher resolution display and some differences of mechanics. CLIs expect you to already know the command used to select your option. As a result, CLIs are only particularly useful once you become familiar with a program. They're fine for people that use a computer like a third lung, because those people have enough familiarity with the interface to know what to hit. CLIs have a number of benefits over GUIs (keyboards have a higher data throughput than mice, CLIs require less processor power, CLIs require less bandwidth for remote use, CLI programs are generally easily scriptable and interfaceable), so for folks familiar with a given program, a CLI is generally worthwhile. For a lightweight computer user, a GUI's advantage of listing all options at any given time simply makes them far, far more efficient, and keyboard shortcuts provide a small measure of the CLI's power that can easily be adopted piecemeal into their working routine.
Current Linux GUIs are generally not completely equivalent to their Windows GUIs because they require the user to map an arbitrary command to what they want to do, yet again (as pointed out in another email, "evolution" means email). However, they are more and more closely approximating this. Plus, the work involved in doing this is comparatively minor relative to writing the masses of software that make up a Linux system. Linux really is 80% of the way to being an acceptable Joe User desktop system.
Word uses the native Windows widget set and drawing engine. OO has to load up a large amount of cross platform code that only it uses during startup. Furthermore, I believe that a fair amount of OO data is stored in XML files, which are comparatively expensive to read and parse at startup time. Mozilla is affected by this as well.
Distro fragmentation is still an issue. What will install and work fine on Red Hat's Fedora Core 1 may not work fine on Slackware.
I'm not sure that a certification system is required. I'd just like to see a website that lists hardware that is *fully supported* under Linux. That means every single feature that the Windows version supports. If a sound card supports hardware reverb on Windows, it should do the same on Linux to be listed. All this means is that I can buy components on this list and not find minor niggling annoyances (like the inability to send Extended Code X10 commands on my X10 controller).
Given that this *may* be somewhat distro-specific, I'd say that it's reasonable to ask distro vendors to provide such lists. These don't have to be current, and they may require someone from the company or someone on a project to send in an email saying "we have full support in". I realize that there are probably political issues involved with having or not having some vendor listed. However, this would be nice from an end user point of view. If I can go to http://www.redhat.com/hardware/ and get a list of sound cards or video cards for which *all features* are supported on my distribution, I can comfortably buy those without spending the remainder of the day reading various experiences of the hardware on Usenet, as I've done in the past.
Chuck, I'd like to point out that whether or not new x86 hardware has an additional protection ring in place (which could be used to implement DRM, among other things), there are a number of questions. Will personal computer DRM catch on in the market at all, despite the efforst of publishers (keep in mind that this is not trivial from a political standpoint)? Will it be implemented in Linux (possible, though there are numerous technical reasons that this will not be easy)? I don't know of anyone that is interested in implementing a Palladium-like system based on TCPA on Linux as an open-source project. If you choose *not* to use TCPA, then you will be in the same boat as Mac OS X users -- if a publisher refuses to produce DRM-less content, then you will simply have to go without that content. If a publisher is willing to produce a DRM-less set of content, then it will probably be available for Linux and Mac OS X.
Also, while it is difficult to produce and support binary-only software for Linux, it is quite legally possible. The GPL states nothing of the sort that you claim. If you use GPLed code or libraries (Note: most libraries are LGPL, not GPL), such as readline, you need to be GPL.
I agree with you that Apple will probably hold out as long as possible on x86 support.
He *could*, but there are 10 billion people on Earth. If each person, at some point during their lifetime, emails Linus, Linus is going to drop a lot of mail.
Also redhat wants rpm to stay so it forces customers to upgrade to avoid having a broken system.
Actually you should write Redhat and mention you would like this ability. Many vendors like Oracle hate getting calls in from angry customers who used their database for RH advanced server 7, upgraded to 8 only to have it break.
I don't think RH did this on purpose. They upgraded to a newer version of Berkley DB, IIRC. It proved to be a rather poor technical decision on their part.
I don't know all the variables involved, but I am very unhappy with whoever at Red Hat is responsible for maintaining RPM. RPM is not a particularly bad system. It's fairly easy for users to use, and good stuff can be built on it. It was written as an evolution of Debian's package system. However, Red Hat has shipped RPM releases in the past that have been completely unacceptably buggy. Red Hat 8.0's out-of-box RPM release was extremely poor. I remember numerous folks that wound up with corrupt databases and RPM hanging. Fedora Core 1 and Red Hat 9 don't seem to have produced this problem, but RPM should be QAed to the degree that the kernel is -- it is simply unacceptable for it to fail. A dying database is a disaster from the standpoint of most end users. Furthermore, the standard recovery techniques were unintuitive, involving deleting some lock files. RPM's spec file format also could be nicer -- it includeds some redundant information and is not, IMHO, nearly as easy to write as it should be.
That being said, RH needs to do a couple of things. First, yum is good. It beats the living snot out of up2date, even if it lacks a synaptic-style front end. However, it has been a royal pain in the ass to figure out the proper RPM repository location to use during the Fedora to Fedora Core transition. Second, it's a pain to upgrade from RPMs -- RH's upgrade path consists of "download ISOs, burn ISOs, choose 'upgrade'". Perhaps I'm just wishing, but I'd really like to just be able to type a single command to yum and upgrade my system. (Actually, I *have* been doing exactly that for years, first by manually downloading RPMs, then with apt, then with yum, but it's never been a Red Hat approved upgrade path). Third, Red Hat needs a good, flowchart-based RPM troubleshooting flowchart. I've seen so many people with problems with RPM in Red Hat 8.0, and it was a royal pain to find proper troubleshooting information. I know one person that gave up on Linux because of RPM DB problems in Red Hat 8.0. I *still* avoid using synaptic with apt on RPM-based systems, because something about how synaptic churns the database appears to expose some sort of race conditions, and periodically hang or corrupt the database. I also make a strict point of only running a single copy of yum at a time, though yum doesn't appear to enforce this behavior.
Slashdot Mirror
It wouldn't take a factory. You could probably build something like this by hand. You can get USB chipsets individually pretty cheaply, and I'd imagine the case is the same for Bluetooth.
No. She humiliated herself in front of everyone.
I don't agree. From at least her standpoint, the reaction to her act was what was humiliating.
That doesn't mean that I don't find the father's reaction understandable. I'd probably be royally pissed off as well. But I also really think that if you have a kid that's old enough to have a cell phone, that kid should also be old enough to decide whether or not they're religious.
Think about this from her situation. My guess is that she didn't want to be there, and was more than willing to make a pain out of herself. She saw that as her only way to gain influence, since clearly she didn't have enough to get herself out of attending in the first place. Now, her father breaking her cell phone *might* have taught her a lesson -- I'm talking about a secondhand story without a lot of detail. However, I've found that generally, folks are more willing to learn if they're at least somewhat empathizing with the other folks. I could see her simply transferring her embarrassment about the phone and the situation to her father and the other people, and complaing about it to her friends. She shouldn't have pulled out the phone, but by way of teaching lessons, neither should be break valuables when he's upset or -- in my opinion -- have taken her to church in the first place if she clearly didn't want to come.
I've had university lecturers who, when a cell rings in their class, stop speaking and simply watch the person whose phone is ringing. Naturally, everyone else turns and looks too. There's no accusation, no sense of "those people are deliberately insulting me", but inevitably the red-faced student is mumbling apologies as they hurry to smack the hangup button.
Oh, I don't know. I really do dislike cell phones -- to the point where, if I could easily obtain and carry a portable jammer, I probably would -- but I just can't help but think that everyone in that church could have probably solved the problem in a kinder way. Heck, these are a group of people kneeling in a *Christian church*. Social issues ignored, what happened to "turn the other cheek"?
So, let's look at this for a moment. The RIAA is trying to standardize something with official meaning for mass electronic distribution. The RIAA is one of the few generally-disliked groups by geeks (even if you disapprove of filesharing, the RIAA hasn't taken the nicest steps in the past to deal with things). They're up there with the Church of Scientology.
I'm going to give even odds that as soon as the first one of these goes out, it'll get posted on the 'Net, and used as propagation fodder for the next Internet email worm (in place of, say, "I Love You") -- so instead of everyone deleting emails containing "I Love You" in the subject, they'll start deleting emails that look like copyright infringement warnings.
Unfortunately smoke grenades in such games are simulated far too poorly; a single smoke grenade should create larger, thicker clouds of smoke much more rapidly; and without microwave radar (requiring a non-man portable emmiter), a sniper cant see you through a cloud of smoke.
This is an incredibly true statement. Smoke as-used-to-obscure-enemy-player-view in video games sucks. A lot.
There are a bunch of problems involved. It's hard to make good-looking smoke without blowing a lot of cycles. The more smoke, the more cycles blown, since smoke's usually implemented as masses and masses of alpha-textured polygons.
The conventional ways of obscuring vision are generally in the form of setting the ambient color (many games do this underwater, and it doesn't work well unless everything is one color), screwing about with gamma levels (doesn't work well unless everything is one color, relatively easy to hack, especially since some video cards may not support gamma level setting), or masses and masses of polygons with a texture with a very high alpha value, which tends to beat up on one's video card.
I'm curious as to what one can do with pixel shaders (which I haven't played with) -- whether volumetric fogs can be approximated. If so, and with pixel shaders becoming more standard, it might be possible to implement a more hack-resistant vision-obscuring effect that looks better.
Although...some folks don't like being *killed* by sniper rifles. Anyone can get a little annoyed, but in 2fort5 in Team Fortress, the kind of snipers that surface are simply inhuman. Furthermore, snipers really *do* rack up insanely high kill ratings.
I'd be interested in seeing a reformed variant of a sniper. Basically, in real life, to the best of my knowledge, sniper rifles aren't used because they're significantly more deadly than another type of rifle. They're used because they're very accurate. I'd be interested in just having a very accurate version of the rifle, and other weapons have progressively higher introduced error.
Adding a scope/crosshairs is also a nice idea, but very vulnerable to hacking -- it's much easier to modify a client's game engine so that it has crosshairs or a high zoom than it is to muck with error, if properly implemented.
Another issue with snipers in games is that conventionally, snipers may be exposed if they try taking on hordes of armed people heading their way. To snag a concept from Snow Crash -- a water tower may make a really great place for a sniper to hang out, but it's also a nice, exposed area where people can shoot. So real life military snipers probably don't want to hang about there, even if they could kill a lot of people from there. In a game, the values are significantly different. People are *willing* to gamble their character's life on a lucrative position that may grant high kill count with no escape route.
Of course, now she has zero chance of willingly going to said church again. She was humiliated in front of everyone, a presumably expensive piece of hardware was broken, and she was whacked.
The easiest solution, methinks, would have been not dragging her to church if she didn't want to go. Trying to force church on the actively disliking is a waste of time and effort.
I find "snooze" as a whole stunningly useless. The whole concept is flawed -- it just treats your brain not to wake up when the alarm goes off, which makes your alarm clock ineffective.
I believe at least some of Europe generally uses 24 hour time (and damned intelligent too -- AFAI can tell, the only reason for 12 hour clocks are analog clocks). Perhaps a Euro-Slashdotter could clear me up on this.
Anyway, if this is the case, a European alarm clock should be 24-hour.
Of course, you might need a voltage adapter.
As a suggestion -- you might consider setting up your computer as an alarm clock. I did so for a while. There are some caveats to consider. If you ever mute your system or plug in headphones, you may end up inadvertently muting your alarm as well. I avoided this by using a Linux box with two soundcards -- one hooked up to the speakers that woke me up. This also let me implement my *other* alarm-clock-most-wanted-feature -- the ability to disable an alarm before it goes off. Nothing pisses me off more than waking up five minutes before my alarm goes off and having the choice of either sitting and waiting for it to go off so that I can flick it off and on again to reset it for the next day, or simply turning it off and hoping that I remember to re-enable it before going to sleep the next day. Very annoying. Oh, and I also had the thing set up to not ring on weekends. God, I hate alarm clocks waking me up on weekends. Perl can make your sleep experience much, much better.
Another feature that you might find useful is kicking the thing off after a minute. If I'm not up after a minute of beeping, I'm not getting up, and it's really annoying to have someone's alarm clock going off because they didn't clear it when away.
They don't really stop you faster than other methods, but they may allow you to steer away from your previous destination, something you could never do if your wheels are completely locked.
Actually, I believe that you are not correct. Maximum "Static" friction that one surface can exert on another is greater than the maximum of the other type (sorry, forget the name...been a while since physics) of friction, the type between moving surfaces. Pulsing the brakes approximates hitting the brakes as hard as you can without actually starting to slide, since static friction is playing a role.
I believe that ABS still (though this could be out of date) can be outdone in practice by a human very familiar with a car's characteristics and the surface they are driving on, like professional race car drivers, since they can very accurately judge the point at which they will begin to slide, and keep the brake just below that.
It's actually really weird -- I don't know about other large SUVs, but the Explorer really is surprisingly awful when it comes to leg room.
You know, I don't really care about the issue one way or another, but I do find it interesting that your source is Ford marketing videos, and the person you're arguing against is actually digging up objective, third party sources.
I see a *lot* of women that put their cell in a purse. Not only does this mean that the vibrate function is useless, but it means that when the audible rings start, they start fumbling around in their bag. Extremely annoying.
The GPL allows Manufacturer X to make software or drivers that are proprietary and not open-source for inclusion in a distro if said works don't include any GPL code? I'll take your word for it for now but will go back and re-read the salient sections of the GPL. I thought that was both legally and ethically forbidden.
Yup. Packaging GPLed and non-GPLed code together is allowed. (For instance, for many years, most Linux distros shipped the closed-source Netscape Communicator suite.) The restriction is on linking -- you may not link non-GPL code to GPL code. This applies to both static linking and dynamic linking. A software package could even have both closed-source and GPL components if the GPLed code was in its own daemon and was communicated with the non-GPL code through a pipe, rather than being linked to it.
I understood that too, but the "Law of Unforseen Circumstances" has a nasty way of jacknifing that reality.
Apple actually included DRM in their own products long before Palladium -- I believe that HFS+ still has (HFS certainly does) a "Copy Protected" flag. The flag has been deprecated for ages upon ages, but it's still in there. I believe it may have been officially deprecated with System 7, but it would take a bigger Apple filesystems guru than I to tell its story.
I would have thought that at *least* when they walk outside of the house into the public area, he'd have the right to video record them, simply because they're in public.
I'm also a little surprised that they were able to say that he couldn't take pictures.
This is trivially defensible in court.
Perhaps not. If I'm taking notes as I'm breaking into a network, and say that "10.31.4.15 IIS DNS vulnerable", that's certainly evidence.
On the other hand, frankly, while having a prescedent of breaking into networks is bad, even if he did it, I hope he gets off on a technicality. The Hungry Programmers have produced a lot of really good free software with huge amounts of their time and talent, benefiting society as a whole. Having them in the wild, instead of behind bars, helps everyone. Valve, on the other hand, has refused to support Linux, has dicked around on their latest release, and generally failed to do nearly as much to make *my* life, at least, better. I'm a lot less sympathetic to a random corporation in it for the money than I am towards really good open source programmers. Talk about "paying a debt to society" -- this guy's done enough to get out of a grand theft rap, in my book.
Plus, if he comes this close to being burned, it's a good bet that he won't be cracking again...
There is a law enforcing this (key/password turnover to law enforcement on demand) in the UK. I'm not sure whether this applies to the US.
Can someone explain to me why we need to get linux running on every desktop in the world exactly??
.doc files, for instance, are not easily readable on non-MS products. MS has significant incentive to deliberately attempt to introduce incompatibility.
.doc files. Since Microsoft is The Institution and tries to isolate itself from other efforts, hackers frequently have to put up with Microsoft's products, even if they do not want to use them.
To say it step-by-step:
1) Hackers like Linux more than Windows. It's a nice, powerful OS.
2) Microsoft sells Windows. It wants people to buy copies of Windows. One major weapon in its arsenal is compatibility --
3) Hackers are not islands. They must interact with other people. Sometimes this means getting DSL service. Sometimes this means having to use a computer specified by an employer. Sometimes this means being able to read
4) Hackers, frusterated with Microsoft, happily work on Linux and other Microsoft-alternative efforts.
Linux having a 30% market share or more would have major benefits (well, and probably drawbacks as well):
* Hardware compatibility. Someone has to write drivers and test and support hardware. It's expensive, so usually this sort of thing is subsidized by lots of people. If many non-hackers are using Linux, then hackers will get hardware support subsidized by non-hackers. This is a Good Thing for them.
* Games. There needs to be a lot of folks willing to buy a game before a company will port, test, and support it on Linux. It's expensive, so usually this sort of thing is subsidized by lots of people. If many non-hackers are using Linux, then hackers will get games subsidized by non-hackers. This is a Good Thing for them.
* Enabling People. Hackers are human too, and they feel good when they let people do something more. It's rather like the digital artist that introduces a conventional photographer to Photoshop. When the photographer's eyes light up and he realizes what he can do, and his ability to produce value increases, the artist feels good, and has helped society. Linux has a number of capabilities that Windows does not, and introducing folks to them would help society.
* DRM. Lots of hackers are not thrilled with the concept of DRM. Establishing a less monopolistic platform rapidly makes it much more difficult for anyone to get everyone using DRM.
* Environment. I'd love to never have to use a Windows box again. However, I run into them. The more people using Linux, the more folks paying people to work on and develop things for Linux, and the less one has to support Windows machines.
* Elimination of proprietary protocols and formats. Only one person directly wins if a proprietary protocol or format is in place -- the vendor of the software using it. Consumers lose, and competitors lose. Linux, having a large collection of entrenched open source and open specification software packages, has a good amount of inertia to not having closed formats.
Now, I grant that there will probably be drawbacks to a dominant Linux. Whatever the dominant easy-to-use distro is, it will likely have security failings, may force people to use a GUI to configure things, and may have a vendor doing all kinds of licensing deals for exclusives (like Microsoft's AOL icon on the desktop). Trojans and viruses will likely be more common for Linux. Politics will become more involved with Linux, just as it did with the Internet (imagine the same thing happening to the FSF that did with ICANN -- being taken over by less-than-nice corporate interests. Ick.) There will be many packages ported, and some of the existing Linux software that appeals to hackers -- small, CLI programs that can easily be combined -- will lose relevance as folks use ported, large, potentially buggy software packages like MS Office. There will probably be more strict backwards compatibility constraints, and cruft will more easily bu
Part of the Linux/Unix fascination is a transformative mindset that confuses cryptic complexity with power and ease-of-use with restricted utility.
I find this terribly ironic, as I have frequently seen the similar sentence "Part of the reason people still use Windows is that they confuse restricted utility with ease-of-use.
More to the point, GUIs really only differ from CLIs in one major way -- they provide a list of your options at any given point, from which you select one. They are very similar to menu-based text interfaces, abeit with a higher resolution display and some differences of mechanics. CLIs expect you to already know the command used to select your option. As a result, CLIs are only particularly useful once you become familiar with a program. They're fine for people that use a computer like a third lung, because those people have enough familiarity with the interface to know what to hit. CLIs have a number of benefits over GUIs (keyboards have a higher data throughput than mice, CLIs require less processor power, CLIs require less bandwidth for remote use, CLI programs are generally easily scriptable and interfaceable), so for folks familiar with a given program, a CLI is generally worthwhile. For a lightweight computer user, a GUI's advantage of listing all options at any given time simply makes them far, far more efficient, and keyboard shortcuts provide a small measure of the CLI's power that can easily be adopted piecemeal into their working routine.
Current Linux GUIs are generally not completely equivalent to their Windows GUIs because they require the user to map an arbitrary command to what they want to do, yet again (as pointed out in another email, "evolution" means email). However, they are more and more closely approximating this. Plus, the work involved in doing this is comparatively minor relative to writing the masses of software that make up a Linux system. Linux really is 80% of the way to being an acceptable Joe User desktop system.
Word uses the native Windows widget set and drawing engine. OO has to load up a large amount of cross platform code that only it uses during startup. Furthermore, I believe that a fair amount of OO data is stored in XML files, which are comparatively expensive to read and parse at startup time. Mozilla is affected by this as well.
Distro fragmentation is still an issue. What will install and work fine on Red Hat's Fedora Core 1 may not work fine on Slackware.
I'm not sure that a certification system is required. I'd just like to see a website that lists hardware that is *fully supported* under Linux. That means every single feature that the Windows version supports. If a sound card supports hardware reverb on Windows, it should do the same on Linux to be listed. All this means is that I can buy components on this list and not find minor niggling annoyances (like the inability to send Extended Code X10 commands on my X10 controller).
Given that this *may* be somewhat distro-specific, I'd say that it's reasonable to ask distro vendors to provide such lists. These don't have to be current, and they may require someone from the company or someone on a project to send in an email saying "we have full support in". I realize that there are probably political issues involved with having or not having some vendor listed. However, this would be nice from an end user point of view. If I can go to http://www.redhat.com/hardware/ and get a list of sound cards or video cards for which *all features* are supported on my distribution, I can comfortably buy those without spending the remainder of the day reading various experiences of the hardware on Usenet, as I've done in the past.
You haven't used Qt then
He has, if he's used Mandrake. Mandrake uses KDE as a default desktop.
Chuck, I'd like to point out that whether or not new x86 hardware has an additional protection ring in place (which could be used to implement DRM, among other things), there are a number of questions. Will personal computer DRM catch on in the market at all, despite the efforst of publishers (keep in mind that this is not trivial from a political standpoint)? Will it be implemented in Linux (possible, though there are numerous technical reasons that this will not be easy)? I don't know of anyone that is interested in implementing a Palladium-like system based on TCPA on Linux as an open-source project. If you choose *not* to use TCPA, then you will be in the same boat as Mac OS X users -- if a publisher refuses to produce DRM-less content, then you will simply have to go without that content. If a publisher is willing to produce a DRM-less set of content, then it will probably be available for Linux and Mac OS X.
Also, while it is difficult to produce and support binary-only software for Linux, it is quite legally possible. The GPL states nothing of the sort that you claim. If you use GPLed code or libraries (Note: most libraries are LGPL, not GPL), such as readline, you need to be GPL.
I agree with you that Apple will probably hold out as long as possible on x86 support.
At least partly because PC games are much more heavily pirated.
He *could*, but there are 10 billion people on Earth. If each person, at some point during their lifetime, emails Linus, Linus is going to drop a lot of mail.
Also redhat wants rpm to stay so it forces customers to upgrade to avoid having a broken system.
Actually you should write Redhat and mention you would like this ability. Many vendors like Oracle hate getting calls in from angry customers who used their database for RH advanced server 7, upgraded to 8 only to have it break.
I don't think RH did this on purpose. They upgraded to a newer version of Berkley DB, IIRC. It proved to be a rather poor technical decision on their part.
I don't know all the variables involved, but I am very unhappy with whoever at Red Hat is responsible for maintaining RPM. RPM is not a particularly bad system. It's fairly easy for users to use, and good stuff can be built on it. It was written as an evolution of Debian's package system. However, Red Hat has shipped RPM releases in the past that have been completely unacceptably buggy. Red Hat 8.0's out-of-box RPM release was extremely poor. I remember numerous folks that wound up with corrupt databases and RPM hanging. Fedora Core 1 and Red Hat 9 don't seem to have produced this problem, but RPM should be QAed to the degree that the kernel is -- it is simply unacceptable for it to fail. A dying database is a disaster from the standpoint of most end users. Furthermore, the standard recovery techniques were unintuitive, involving deleting some lock files. RPM's spec file format also could be nicer -- it includeds some redundant information and is not, IMHO, nearly as easy to write as it should be.
That being said, RH needs to do a couple of things. First, yum is good. It beats the living snot out of up2date, even if it lacks a synaptic-style front end. However, it has been a royal pain in the ass to figure out the proper RPM repository location to use during the Fedora to Fedora Core transition. Second, it's a pain to upgrade from RPMs -- RH's upgrade path consists of "download ISOs, burn ISOs, choose 'upgrade'". Perhaps I'm just wishing, but I'd really like to just be able to type a single command to yum and upgrade my system. (Actually, I *have* been doing exactly that for years, first by manually downloading RPMs, then with apt, then with yum, but it's never been a Red Hat approved upgrade path). Third, Red Hat needs a good, flowchart-based RPM troubleshooting flowchart. I've seen so many people with problems with RPM in Red Hat 8.0, and it was a royal pain to find proper troubleshooting information. I know one person that gave up on Linux because of RPM DB problems in Red Hat 8.0. I *still* avoid using synaptic with apt on RPM-based systems, because something about how synaptic churns the database appears to expose some sort of race conditions, and periodically hang or corrupt the database. I also make a strict point of only running a single copy of yum at a time, though yum doesn't appear to enforce this behavior.