Interestingly, whenever the media lists a group of Eastern states with some kind of category, like "Mid-Atlantic states", "Northeast states", or "Southeast states", Delaware is *always* left off the list.
Delaware is bordered by PA on the north, NJ/ocean on the east, and MD on the west and south. I've seen the category "Mid-Atlantic" repeatedly used with the following configurations (working from north of DE to south of DE):
+ NY, PA, NJ + PA, NJ, MD + NJ, MD, VA + etc -- no DE.
Same goes for "Northeast States". They always stop at PA and NJ. "Southeast States", if they make it up to the mid-atlantic region at all, stop at MD. So, according to various media, we're not in the north, south, or middle region. Consequently, the public rarely gets any off-hand mental reinforcement of our existence or location.
I'm from DE, and it's kinda fun being off the radar. We're not even recognized regularly for being the smallest state -- we're just the second smallest, so RI gets the recognition there.
Heck, in the old days....if you only had one quarter left..you could still play with a friend...each of you takes a flipper.... Man, that takes me back. Nice observation. I still do that with my girlfriend.
0. Doing no programming is easy. 1. Programming single-threaded is harder than (0). 2. Programming multi-threaded is harder than (1).
Some people fail doing (1), and others succeed. More people fail at (2) than (1), and less others succeed at (2) than (1).
Just because more people fail at (2) than (1), is that enough to say that multi-threaded programming failed? If we have failures at (1), should we claim that all programming is worthless? What's the threshold of failure that says that multi-threading is completely untenable vs. single-threading, but single-threading is tenable vs. no programming.
Given the population's general software failure rate, I bet we have even more research dollars going into improving general (single-threaded) programming. By your argument, that seems to suggest that computer programming overall, regardless of thread count, has failed.
I agree that multi-threaded programming can and should be improved, and also that if we can find a better way to parallelism than "threads", let's go for it. If it's "better", then by definition it's better, so what's the argument?
I think he's only a pompous ass if you can prove that there's already a clear alternative to programming multi-threaded and that nobody should be programming multi-threaded.
I've said it before in an obscure forum post that no one in their right mind read, and I'll say it again:
Create a layered Wikipedia, where the top layer contains the refined or lay-person content, and the lower layer(s) contain technical or esoteric details on particular topics. Users looking for more information can drill down to lower topic layers.
Why can't or shouldn't musical artists make money from album sales? How is this different from a movie or TV company making money from DVD sales?
Considering that movies are much more expensive to make than audio albums, it's even more confusing. Some movies take a loss in their "live performance" phase only to make it up with the DVD sales, so I don't necessarily believe that DVD sales are just extra profits.
The distribution, marketing, and availability models are different between music, TV, and movies. Does this explain why music artists can't make money off their recordings? Is their a difference in the supply/demand curves between albums and movies?
It seems to me the big deal is whether Wikipedia should include technical details, vs. just lay-introductions. This affects lots of areas of Wikipedia, not just mathematics. I have found the technical details that are available on Wikipedia to be invaluable to me at work and I would hate to see them go.
If they are afraid of turning people away from including too much technical details in articles, why not offer 1 or more layers of articles? For example, the lay-introduction, and then links to backing pages with more details. It seems silly to deliberately dispose of knowledge that people are offering, unless there are storage or bandwidth considerations, which I doubt will be a significant issue in the future (if it even is now).
Wikipedia is growing beyond the idea of a basic encyclopedia, into a type of knowledge base that the world has never seen before. I don't see why it can't serve as both a basic encyclopedia and as a source of advanced knowledge. People are pushing it that way, and it is incredibly useful. It has become very attractive to people wanting to share knowledge, and constraining it to the concept of a basic encyclopedia is just throwing away not only a lot of useful effort on the part of many contributors, but the momentum by those contributors to have a central store of knowledge. Wikipedia is where they are attracted to put their advanced knowledge. If Wikipedia shuts that down, it will be difficult to establish another central location, and when one is established, there will be conflicts of overlap with Wikipedia.
It shouldn't be that difficult to establish "knowledge layers" that satisfy both parties.
You're right. My sample size regarding OS/X stability is entirely too small to support my conclusion, and I spent too much time developing points based on that shaky conclusion. I had an uneasy feeling when I was writing that part -- I should have recognized it more clearly as ass-talking.
I do miss working with Macs. I learned how to use them in the 80's, loved using QuarkExpress to lay out my high school newspaper, and used to support a Mac lab for the education department of my university in the 90's (as well as various department Macs and PCs). They have always been superior in terms of ease-of-use and troubleshooting. I looked through the new OS/X APIs way back when it was released but haven't developed with them. They looked much cleaner than what Windows had at the time. I assume they still are, considering that I think.NET leaves you in managed-code land (?), such that you're still stuck with crappy Win32/MFC if you want to compile natively (I could be wrong). I would love to see things swing toward Mac again, at least as a kind of public trial, to see if Apple can keep up.
Right now I'm running Windows XP on a Pentium 3 450 with 128 MB ram. While I can't do very much with it, it hasn't crashed when I tried to do a lot with it. It bogs down like you'd expect and then eventually recovers. On the high-end workstations and product prototypes at work, XP crashes maybe once every four months per computer. On my mom's computer, once a year. Friends' computers are a mixed bag -- mostly very stable, but one guy I know who has a non-reimaged Dell XPS couldn't make it 2 hours without a crash. I have 2 data points on OS/X: a PowerBook user doing typical desktop stuff and a recording studio doing audio recording. I don't know the shapes of their computers, but they have stability problems. Which is the worst thing to have when you're doing audio recording (losing a take kills -- multiple crashes every recording session), and which probably influenced my poor decision to push on with a conclusion based on little evidence.
Anyway, when Mac/x86 comes out, and if/when it supports Windows, I will seriously consider trying to get a cheap one to see what it's like. I'm platform agnostic -- consider as many factors as you can then choose what fits best.
My impression is that the technology surrounding the x86, e.g., the system bus, etc., has had a lot more development geared towards whatever PC's are typically used for (like desktop and server stuff), whereas the PowerPC line, and certainly the Cell, have not. This would have been due to x86 having such a large market share and many companies and people targetting there development towards it. This resulted in the x86 system architectures outpacing smaller-share competitors and being able to deliver much more performance, as far as a desktop, server, or scientific user is concerned. So Apple, which produces computers mainly targetted towards the desktop, decided to go with x86 CPUs to finally stop being hamstrung by "the rest of the computer". Apple can design a basically good motherboard, but they're the only ones doing it for the PowerPC on the desktop. x86 has 20 companies doing it, and with that amount of effort and competition, the results are better.
Apple's other problem with selling computers is that low third-party software availability makes the hardware less attractive. I assume that while it won't necessarily be any easier to port a Windows/x86 program to OSX/x86, it won't be any harder. It will be easier though for them to put some kind of emulation layer in there to make it easier for Windows progams or "half-ported" programs to run, or at least have a virtual PC that will run Windows to run Windows programs (or dual-boot). Reports from friends who run current Macs though are that OS/X is not the most stable operating system. I believe it probably has a better general software architecture and code, just that it hasn't gotten as much testing or rigorous use due to the smaller size of Apple and its user base. Windows (surprisingly) seems much more stable than OS/X. So the wisdom of running Windows inside of a virtual PC inside OS/X is debatable. With the increase in market share for Apple that I think will be coming, their reliability may improve. I'd certainly prefer to work with a Unix-based system and clean OS API over the pile of closed spaghetti code that is Windows. I think they're counting on people deciding that an Apple computer that can run either OS/X or Windows is better than a non-Apple computer that can only run Windows.
I hope they go on to show that sleeping is like being passed out. I think we need to make this absolutely clear. In case anyone was just sleeping 5 minutes ago.
Unfortunately it was late and I didn't "refer to them" enough (too early in the morning, just got home from a live show).
I think you're right and I'm wrong about the implementation, but I think it is a flaw not to have the mail auto-statistics-gathered when it is auto-classified.
As it stands, mail that is not manually marked either way by the user is considered neutral as far as statistics gathering goes. (Even though there is no "neutral" display/description on it and the system will still show its automatically-determined junk classification).
When statistics are gathered on a message (when it is manually marked either way), the statistics can be "undone" and "redone" in the opposite direction by manually toggling the mark on the message.
It is true that a feedback loop will develop to degrade filtering if the system were to auto-statistics-gather when it auto-classifies, but only if the user doesn't make corrections. They've declared that for the system to work, the user must declare spam, ham, and/make corrections/. (And they seem to emphasize also making corrections). In fact, the way the default system is presented (user interface), it looks like you only have to make corrections, and this appears to be what people are assuming.
So my (new) point is that so long as they're asking the user to make corrections, it doesn't make any sense not to have the mail auto-statistics-gathered on arrival when it is auto-classified. Users "have" to correct it anyway. Once they understand the system, they'll almost certainly be correcting false positives, and should be happily marking junk that was incorrectly labelled non-junk, so all that's left is correctly identified mail. Why bother to "remark", as it were, only to get the system to analyze it. To have to deliberately mark already correctly marked messages is a waste of time, especially when the user it already asked to toggle incorrectly marked messages.
Deliberately marking correctly marked messages also means you have to mark every message you receive one way or the other. That's a waste especially when (over time) the system is correctly marking most of them.
I can see some small usefulness in not auto-statistics-gathering, but I think the advantages of auto-gathering outweigh the non-gathering, especially since I have carpal tunnel and have to save my mouse moves, clicks, and typing.
Why should I bother marking junk that eventually will get auto-moved to a junk folder? Why should I bother marking all my non-junk that is probably already marked non-junk? I will definitely bother to mark junk that wasn't marked before as junk (probably won't be that much after a short time, according to reports). And I'll definitely mark as non-junk false-positives (apparently also not that much). Correctly identified mail will make up the bulk of the messages you receive, and by using auto-gathering, you only have to mark the lesser portion of your mail (incorrectly marked mail).
As it stands, you have to mark -every- message to get statistics gathering, which practically defeats the purpose of the system. You can get equivalent statistics gathering by just auto-gathering and making corrections, which will work for users because people are encouraged to make corrections already and that appears to be what they are doing.
It's true that the purpose of the system is to get junk out of your way, which it will do if you've collected enough basic statistics and don't bother to collect any more (except on corrections), but by definiton the system only works if you keep making corrections so I think you might as well auto-gather if users "have" to make corrections regardless.
It's also true that mathematically after a certain point statistics may not have to be gathered for any mail that doesn't need to be corrected (as long as falsely-identified mail is corrected and stats are gath
To clarify this, you only need to manually mark messages as junk or non-junk that have been incorrectly classified (either way).
That is, if the mail is already correctly auto-classified as ham, then you don't need to touch it -- it will be analyzed and data on it will be saved. If it is correctly auto-classified as junk, then the same applies -- you don't need to change it.
If it is incorrectly classified as junk (i.e., it is ham but marked as spam), then you should reclassify it as ham (mark as non junk; toggle the junk icon) for the system to learn correctly.
Likewise if it is incorrectly classified as non-junk (i.e., it is spam but marked as ham) -- reclassify it as junk to for the system to learn correctly.
As far as Lasik is concerned, I'd be worried about the effect staring at a CRT monitor has on your eyes in the following way:
Staring at a CRT monitor all day tends to result in blurrier and blurrier vision over time. As I've read and understand it, CRT's are inherently blurry at a very small and mostly conscsiously undetectable level. When you stare at them all day, (especially text) your eyes are automatically and constantly trying to focus on this inherent blurriness (which you don't really notice). By the end of the day (or sooner), when you get up to leave, you'll find that over time you'll have a hard time focusing on things (they get blurrier) since the muscles that control focus are completely tired out from overexerting themselves all day (when they wouldn't have to normally). (Note humans did not evolve in a world with lots of blurry edges). This leads to worse vision.
It can be reversed -- not using CRTs (LCDs are much sharper in this regard -- I think this is the primary reason people report less eye-fatigue with them) and getting up and moving around a lot during the day (healthy anyway for programmers) to give your eyes a break (and simultaneously keep them warm) seem to be the main things that help.
(Getting up and moving around is also important to help prevent other body injuries that can happen when you sit around too long).
Anyway, I think a problem might come in if you have surgery and one day you stop programming or sitting behind a computer for an extended period of time every day (job change, etc). If your muscles eventually recuperate, what will that do to your already-corrected vision? Will your eyes over-focus? With glasses, you can just get less-strong glasses to meet your improving vision. But two or more surgeries doesn't sound good, or glasses again seems pointless after the surgery.
I can attest to having my vision get worse and better depending on my computer usage and exerise level. Most eye doctors don't seem aware of the CRT connection though, even though I know one person who confirmed it with her doctor and I've read about it. And of course, when a doctor hasn't read a journal article on it, they couldn't care less. (When they have read a journal article on it, uh, that doesn't seem to help too much either:p).
I agree that untested patches tend to be dangerous, but there's another problem: sometimes the makers of the proprietary software being used just won't release a patch to fix an important problem a set of users are having. I've been on both sides of that, where we needed a patch that the company wouldn't release, and where my company wasn't interested in fixing some problems for a few users for various reasons (usually development time vs. returns). This is extremely common.
If the users in either of those cases had open source, they wouldn't have had to beat their heads against the makers indefinitely. They could have either fixed it and tested it themselves, or paid someone else to fix it and test it. If it was proprietary, they could have paid us (the software maker) to fix it and test it, which one might say is practically the same thing, except that (I hate this) we probably wouldn't have done it. Development teams usually have a finite amount of time and tend to spend it developing features and fixing bugs that will generate the most sales. Even if a user compensated the proprietary team for their development time to fix a single specific problem, the team would probably want to instead spend that time on fixing features that would affect more users for more sales. These fixes that get skipped by developers are usually the ones that affect one customer and don't have much benefit for other customers, current or potential, at least as far as the team believes, so unless the user wanting that problem fixed is willing to compensate extra to make up for sales lost by not developing other features/fixes, then the team is probably going to decide against it. (There usually aren't exact numbers about who wants what and how many sales it will generate, but there definitely are fuzzy ones, and you have to work with something). A user probably wouldn't do that, and as a user, I'd rather just have the source to make my own decisions. I wish there was some other way, because I hate leaving stuff unfixed or leaving a user unhappy.
I wonder if there is an argment also for users of open source where they can decide how much testing is appropriate for their system. What do you think... possible in the general pattern of open source development? Or only applicable if you're doing the testing yourself?
Next to that, I'd love to see what kind and how much testing gets done on open source vs. closed source. Do you think it gets a much higher quantity (like beta testing) than closed source testing gets? (Not a rhetorical question... I don't know). I can imagine Apache potentially getting a couple of magnitude more "testers" on it right after a patch release -- light users, experimenters, etc., than an equivalent closed source project. I don't know though -- I'd love to see what the usage patterns look like for open and closed projects right after the first successful compile (completely untested) to the point where "it's working".
While the Mac Classic may not have been rooted, it was also not designed to provide 24/365 network services, multi-user protection, etc. Linux is generally designed as a Unix clone, which was generally designed to provide services to multiple users, either via shells or served some other way over the network (web server, database, thin client server, etc.). In order for Linux to offer this, it has to provide the ability for some people to have access and not others. Any time services like that are offered with selective access, security problems exist -- it's a natural part of trying to identify entities -- everything can be spoofed at some level. Hence the mantra, "Nothing is ever totally secure."
The Mac Classic (as far as I know) does not offer a web server, network databasing, remote shells, etc. If it does, the Mac OS (9 or before that the Classic runs on) is not stable enough to provide these service reliably: there's no memory protection, and there's no way to log in remotely to fix problems. If those services were provided on the Mac Classic, you would have seen remote root exploits happening.
Another way of putting it -- what can you do on a rooted Mac Classic? That's like somebody rooting my watch. There's nothing to do with my watch once it's been rooted, and in any case, my watch doesn't really offer the ability for remote control, much less a root environment versus a non-admin environment. Whoever's sitting at my watch (or whoever my watch is sitting on) has control, and there is no other option.
Also, root exploits are not the only exploits. Crashing a computer remotely is an exploit also (one thing root exploits are used to achieve). Even if the Mac Classic does not offer a remote shell (as far as I know), how hard is it to crash remotely? I worked in a Macintosh computer lab, where the Apples went down constantly because of bad network data. We sometimes couldn't put particular protocols on the ethernet because OS 6/7 couldn't handle it. I suspect that if people tried, it would not have been that hard. (I'm not anti-Apple -- I think that most every kind of computer has appropriate uses).
Since Mac OS X offers the afore-mentioned services, I suspect that if its use increases, we'll start to see remote exploits happening. This has nothing to do with it being Unix based -- it's a result of what I said before -- any system which offers services or grants selective access based on an identification can and will be exploited.
I haven't read the paper yet, but I would say that if generally any two particular pieces of software have the same number of bugs or security issues, the open source software will benefit technical server groups more for the ability of those groups to analyze the code and make their own fixes if necessary, and for the way in which the community generally very quickly responds to discovered flaws. Closed source software does not tend to respond as fast or offer the flexibility of allowing users to analyze the code. Of course, I haven't read the paper yet. Maybe they take that into account.
Slashdot Mirror
> ... that blur the line between cellphone and home PC.
I always wanted a desktop cellphone.
Interestingly, whenever the media lists a group of Eastern states with some kind of category, like "Mid-Atlantic states", "Northeast states", or "Southeast states", Delaware is *always* left off the list.
Delaware is bordered by PA on the north, NJ/ocean on the east, and MD on the west and south. I've seen the category "Mid-Atlantic" repeatedly used with the following configurations (working from north of DE to south of DE):
+ NY, PA, NJ
+ PA, NJ, MD
+ NJ, MD, VA
+ etc -- no DE.
Same goes for "Northeast States". They always stop at PA and NJ. "Southeast States", if they make it up to the mid-atlantic region at all, stop at MD. So, according to various media, we're not in the north, south, or middle region. Consequently, the public rarely gets any off-hand mental reinforcement of our existence or location.
I'm from DE, and it's kinda fun being off the radar. We're not even recognized regularly for being the smallest state -- we're just the second smallest, so RI gets the recognition there.
If we can't get it from their tears, we'll take it from their blood.
In defense of the other Anonymous Coward:
0. Doing no programming is easy.
1. Programming single-threaded is harder than (0).
2. Programming multi-threaded is harder than (1).
Some people fail doing (1), and others succeed.
More people fail at (2) than (1), and less others succeed at (2) than (1).
Just because more people fail at (2) than (1), is that enough to say that multi-threaded programming failed? If we have failures at (1), should we claim that all programming is worthless? What's the threshold of failure that says that multi-threading is completely untenable vs. single-threading, but single-threading is tenable vs. no programming.
Given the population's general software failure rate, I bet we have even more research dollars going into improving general (single-threaded) programming. By your argument, that seems to suggest that computer programming overall, regardless of thread count, has failed.
I agree that multi-threaded programming can and should be improved, and also that if we can find a better way to parallelism than "threads", let's go for it. If it's "better", then by definition it's better, so what's the argument?
I think he's only a pompous ass if you can prove that there's already a clear alternative to programming multi-threaded and that nobody should be programming multi-threaded.
I've said it before in an obscure forum post that no one in their right mind read, and I'll say it again:
Create a layered Wikipedia, where the top layer contains the refined or lay-person content, and the lower layer(s) contain technical or esoteric details on particular topics. Users looking for more information can drill down to lower topic layers.
Why can't or shouldn't musical artists make money from album sales? How is this different from a movie or TV company making money from DVD sales?
Considering that movies are much more expensive to make than audio albums, it's even more confusing. Some movies take a loss in their "live performance" phase only to make it up with the DVD sales, so I don't necessarily believe that DVD sales are just extra profits.
The distribution, marketing, and availability models are different between music, TV, and movies. Does this explain why music artists can't make money off their recordings? Is their a difference in the supply/demand curves between albums and movies?
It seems to me the big deal is whether Wikipedia should include technical details, vs. just lay-introductions. This affects lots of areas of Wikipedia, not just mathematics. I have found the technical details that are available on Wikipedia to be invaluable to me at work and I would hate to see them go.
If they are afraid of turning people away from including too much technical details in articles, why not offer 1 or more layers of articles? For example, the lay-introduction, and then links to backing pages with more details. It seems silly to deliberately dispose of knowledge that people are offering, unless there are storage or bandwidth considerations, which I doubt will be a significant issue in the future (if it even is now).
Wikipedia is growing beyond the idea of a basic encyclopedia, into a type of knowledge base that the world has never seen before. I don't see why it can't serve as both a basic encyclopedia and as a source of advanced knowledge. People are pushing it that way, and it is incredibly useful. It has become very attractive to people wanting to share knowledge, and constraining it to the concept of a basic encyclopedia is just throwing away not only a lot of useful effort on the part of many contributors, but the momentum by those contributors to have a central store of knowledge. Wikipedia is where they are attracted to put their advanced knowledge. If Wikipedia shuts that down, it will be difficult to establish another central location, and when one is established, there will be conflicts of overlap with Wikipedia.
It shouldn't be that difficult to establish "knowledge layers" that satisfy both parties.
By robots, he means high-quality, live-action actors under Lucas's direction, right?
You're right. My sample size regarding OS/X stability is entirely too small to support my conclusion, and I spent too much time developing points based on that shaky conclusion. I had an uneasy feeling when I was writing that part -- I should have recognized it more clearly as ass-talking.
.NET leaves you in managed-code land (?), such that you're still stuck with crappy Win32/MFC if you want to compile natively (I could be wrong). I would love to see things swing toward Mac again, at least as a kind of public trial, to see if Apple can keep up.
I do miss working with Macs. I learned how to use them in the 80's, loved using QuarkExpress to lay out my high school newspaper, and used to support a Mac lab for the education department of my university in the 90's (as well as various department Macs and PCs). They have always been superior in terms of ease-of-use and troubleshooting. I looked through the new OS/X APIs way back when it was released but haven't developed with them. They looked much cleaner than what Windows had at the time. I assume they still are, considering that I think
Right now I'm running Windows XP on a Pentium 3 450 with 128 MB ram. While I can't do very much with it, it hasn't crashed when I tried to do a lot with it. It bogs down like you'd expect and then eventually recovers. On the high-end workstations and product prototypes at work, XP crashes maybe once every four months per computer. On my mom's computer, once a year. Friends' computers are a mixed bag -- mostly very stable, but one guy I know who has a non-reimaged Dell XPS couldn't make it 2 hours without a crash. I have 2 data points on OS/X: a PowerBook user doing typical desktop stuff and a recording studio doing audio recording. I don't know the shapes of their computers, but they have stability problems. Which is the worst thing to have when you're doing audio recording (losing a take kills -- multiple crashes every recording session), and which probably influenced my poor decision to push on with a conclusion based on little evidence.
Anyway, when Mac/x86 comes out, and if/when it supports Windows, I will seriously consider trying to get a cheap one to see what it's like. I'm platform agnostic -- consider as many factors as you can then choose what fits best.
My impression is that the technology surrounding the x86, e.g., the system bus, etc., has had a lot more development geared towards whatever PC's are typically used for (like desktop and server stuff), whereas the PowerPC line, and certainly the Cell, have not. This would have been due to x86 having such a large market share and many companies and people targetting there development towards it. This resulted in the x86 system architectures outpacing smaller-share competitors and being able to deliver much more performance, as far as a desktop, server, or scientific user is concerned. So Apple, which produces computers mainly targetted towards the desktop, decided to go with x86 CPUs to finally stop being hamstrung by "the rest of the computer". Apple can design a basically good motherboard, but they're the only ones doing it for the PowerPC on the desktop. x86 has 20 companies doing it, and with that amount of effort and competition, the results are better.
Apple's other problem with selling computers is that low third-party software availability makes the hardware less attractive. I assume that while it won't necessarily be any easier to port a Windows/x86 program to OSX/x86, it won't be any harder. It will be easier though for them to put some kind of emulation layer in there to make it easier for Windows progams or "half-ported" programs to run, or at least have a virtual PC that will run Windows to run Windows programs (or dual-boot). Reports from friends who run current Macs though are that OS/X is not the most stable operating system. I believe it probably has a better general software architecture and code, just that it hasn't gotten as much testing or rigorous use due to the smaller size of Apple and its user base. Windows (surprisingly) seems much more stable than OS/X. So the wisdom of running Windows inside of a virtual PC inside OS/X is debatable. With the increase in market share for Apple that I think will be coming, their reliability may improve. I'd certainly prefer to work with a Unix-based system and clean OS API over the pile of closed spaghetti code that is Windows. I think they're counting on people deciding that an Apple computer that can run either OS/X or Windows is better than a non-Apple computer that can only run Windows.
(Sorry, that went offtopic).
I hope they go on to show that sleeping is like being passed out. I think we need to make this absolutely clear. In case anyone was just sleeping 5 minutes ago.
If there's not heavy use of helmet cam shots, then it won't feel real enough.
Pentalon
_caps_lock_is_not_dead_stop_it_is_still_used_for_t elegrams_stop_telegrams_are_dead_stop_
You know these people that role play are usually the ones that right your software.
Right my software? If only, but it's still fantasy.
Ballmer's right -- stability isn't an innovation. Good design isn't an innovation. These are all concepts that existed years ago.
I was referring to the set of notes linked to at:
/make corrections/. (And they seem to emphasize also making corrections). In fact, the way the default system is presented (user interface), it looks like you only have to make corrections, and this appears to be what people are assuming.
http://www.mozilla.org/mailnews/spam.html
Unfortunately it was late and I didn't "refer to them" enough (too early in the morning, just got home from a live show).
I think you're right and I'm wrong about the implementation, but I think it is a flaw not to have the mail auto-statistics-gathered when it is auto-classified.
As it stands, mail that is not manually marked either way by the user is considered neutral as far as statistics gathering goes. (Even though there is no "neutral" display/description on it and the system will still show its automatically-determined junk classification).
When statistics are gathered on a message (when it is manually marked either way), the statistics can be "undone" and "redone" in the opposite direction by manually toggling the mark on the message.
It is true that a feedback loop will develop to degrade filtering if the system were to auto-statistics-gather when it auto-classifies, but only if the user doesn't make corrections. They've declared that for the system to work, the user must declare spam, ham, and
So my (new) point is that so long as they're asking the user to make corrections, it doesn't make any sense not to have the mail auto-statistics-gathered on arrival when it is auto-classified. Users "have" to correct it anyway. Once they understand the system, they'll almost certainly be correcting false positives, and should be happily marking junk that was incorrectly labelled non-junk, so all that's left is correctly identified mail. Why bother to "remark", as it were, only to get the system to analyze it. To have to deliberately mark already correctly marked messages is a waste of time, especially when the user it already asked to toggle incorrectly marked messages.
Deliberately marking correctly marked messages also means you have to mark every message you receive one way or the other. That's a waste especially when (over time) the system is correctly marking most of them.
I can see some small usefulness in not auto-statistics-gathering, but I think the advantages of auto-gathering outweigh the non-gathering, especially since I have carpal tunnel and have to save my mouse moves, clicks, and typing.
Why should I bother marking junk that eventually will get auto-moved to a junk folder? Why should I bother marking all my non-junk that is probably already marked non-junk? I will definitely bother to mark junk that wasn't marked before as junk (probably won't be that much after a short time, according to reports). And I'll definitely mark as non-junk false-positives (apparently also not that much). Correctly identified mail will make up the bulk of the messages you receive, and by using auto-gathering, you only have to mark the lesser portion of your mail (incorrectly marked mail).
As it stands, you have to mark -every- message to get statistics gathering, which practically defeats the purpose of the system. You can get equivalent statistics gathering by just auto-gathering and making corrections, which will work for users because people are encouraged to make corrections already and that appears to be what they are doing.
It's true that the purpose of the system is to get junk out of your way, which it will do if you've collected enough basic statistics and don't bother to collect any more (except on corrections), but by definiton the system only works if you keep making corrections so I think you might as well auto-gather if users "have" to make corrections regardless.
It's also true that mathematically after a certain point statistics may not have to be gathered for any mail that doesn't need to be corrected (as long as falsely-identified mail is corrected and stats are gath
To clarify this, you only need to manually mark messages as junk or non-junk that have been incorrectly classified (either way).
That is, if the mail is already correctly auto-classified as ham, then you don't need to touch it -- it will be analyzed and data on it will be saved. If it is correctly auto-classified as junk, then the same applies -- you don't need to change it.
If it is incorrectly classified as junk (i.e., it is ham but marked as spam), then you should reclassify it as ham (mark as non junk; toggle the junk icon) for the system to learn correctly.
Likewise if it is incorrectly classified as non-junk (i.e., it is spam but marked as ham) -- reclassify it as junk to for the system to learn correctly.
Derek
Maybe if we can point them at the AOL shipping warehouse, they'll all disappear in a puff of logic.
Derek
As far as Lasik is concerned, I'd be worried about the effect staring at a CRT monitor has on your eyes in the following way:
:p).
Staring at a CRT monitor all day tends to result in blurrier and blurrier vision over time. As I've read and understand it, CRT's are inherently blurry at a very small and mostly conscsiously undetectable level. When you stare at them all day, (especially text) your eyes are automatically and constantly trying to focus on this inherent blurriness (which you don't really notice). By the end of the day (or sooner), when you get up to leave, you'll find that over time you'll have a hard time focusing on things (they get blurrier) since the muscles that control focus are completely tired out from overexerting themselves all day (when they wouldn't have to normally). (Note humans did not evolve in a world with lots of blurry edges). This leads to worse vision.
It can be reversed -- not using CRTs (LCDs are much sharper in this regard -- I think this is the primary reason people report less eye-fatigue with them) and getting up and moving around a lot during the day (healthy anyway for programmers) to give your eyes a break (and simultaneously keep them warm) seem to be the main things that help.
(Getting up and moving around is also important to help prevent other body injuries that can happen when you sit around too long).
Anyway, I think a problem might come in if you have surgery and one day you stop programming or sitting behind a computer for an extended period of time every day (job change, etc). If your muscles eventually recuperate, what will that do to your already-corrected vision? Will your eyes over-focus? With glasses, you can just get less-strong glasses to meet your improving vision. But two or more surgeries doesn't sound good, or glasses again seems pointless after the surgery.
I can attest to having my vision get worse and better depending on my computer usage and exerise level. Most eye doctors don't seem aware of the CRT connection though, even though I know one person who confirmed it with her doctor and I've read about it. And of course, when a doctor hasn't read a journal article on it, they couldn't care less. (When they have read a journal article on it, uh, that doesn't seem to help too much either
Derek
I agree that untested patches tend to be dangerous, but there's another problem: sometimes the makers of the proprietary software being used just won't release a patch to fix an important problem a set of users are having. I've been on both sides of that, where we needed a patch that the company wouldn't release, and where my company wasn't interested in fixing some problems for a few users for various reasons (usually development time vs. returns). This is extremely common.
... possible in the general pattern of open source development? Or only applicable if you're doing the testing yourself?
... I don't know). I can imagine Apache potentially getting a couple of magnitude more "testers" on it right after a patch release -- light users, experimenters, etc., than an equivalent closed source project. I don't know though -- I'd love to see what the usage patterns look like for open and closed projects right after the first successful compile (completely untested) to the point where "it's working".
If the users in either of those cases had open source, they wouldn't have had to beat their heads against the makers indefinitely. They could have either fixed it and tested it themselves, or paid someone else to fix it and test it. If it was proprietary, they could have paid us (the software maker) to fix it and test it, which one might say is practically the same thing, except that (I hate this) we probably wouldn't have done it. Development teams usually have a finite amount of time and tend to spend it developing features and fixing bugs that will generate the most sales. Even if a user compensated the proprietary team for their development time to fix a single specific problem, the team would probably want to instead spend that time on fixing features that would affect more users for more sales. These fixes that get skipped by developers are usually the ones that affect one customer and don't have much benefit for other customers, current or potential, at least as far as the team believes, so unless the user wanting that problem fixed is willing to compensate extra to make up for sales lost by not developing other features/fixes, then the team is probably going to decide against it. (There usually aren't exact numbers about who wants what and how many sales it will generate, but there definitely are fuzzy ones, and you have to work with something). A user probably wouldn't do that, and as a user, I'd rather just have the source to make my own decisions. I wish there was some other way, because I hate leaving stuff unfixed or leaving a user unhappy.
I wonder if there is an argment also for users of open source where they can decide how much testing is appropriate for their system. What do you think
Next to that, I'd love to see what kind and how much testing gets done on open source vs. closed source. Do you think it gets a much higher quantity (like beta testing) than closed source testing gets? (Not a rhetorical question
While the Mac Classic may not have been rooted, it was also not designed to provide 24/365 network services, multi-user protection, etc. Linux is generally designed as a Unix clone, which was generally designed to provide services to multiple users, either via shells or served some other way over the network (web server, database, thin client server, etc.). In order for Linux to offer this, it has to provide the ability for some people to have access and not others. Any time services like that are offered with selective access, security problems exist -- it's a natural part of trying to identify entities -- everything can be spoofed at some level. Hence the mantra, "Nothing is ever totally secure."
The Mac Classic (as far as I know) does not offer a web server, network databasing, remote shells, etc. If it does, the Mac OS (9 or before that the Classic runs on) is not stable enough to provide these service reliably: there's no memory protection, and there's no way to log in remotely to fix problems. If those services were provided on the Mac Classic, you would have seen remote root exploits happening.
Another way of putting it -- what can you do on a rooted Mac Classic? That's like somebody rooting my watch. There's nothing to do with my watch once it's been rooted, and in any case, my watch doesn't really offer the ability for remote control, much less a root environment versus a non-admin environment. Whoever's sitting at my watch (or whoever my watch is sitting on) has control, and there is no other option.
Also, root exploits are not the only exploits. Crashing a computer remotely is an exploit also (one thing root exploits are used to achieve). Even if the Mac Classic does not offer a remote shell (as far as I know), how hard is it to crash remotely? I worked in a Macintosh computer lab, where the Apples went down constantly because of bad network data. We sometimes couldn't put particular protocols on the ethernet because OS 6/7 couldn't handle it. I suspect that if people tried, it would not have been that hard. (I'm not anti-Apple -- I think that most every kind of computer has appropriate uses).
Since Mac OS X offers the afore-mentioned services, I suspect that if its use increases, we'll start to see remote exploits happening. This has nothing to do with it being Unix based -- it's a result of what I said before -- any system which offers services or grants selective access based on an identification can and will be exploited.
I haven't read the paper yet, but I would say that if generally any two particular pieces of software have the same number of bugs or security issues, the open source software will benefit technical server groups more for the ability of those groups to analyze the code and make their own fixes if necessary, and for the way in which the community generally very quickly responds to discovered flaws. Closed source software does not tend to respond as fast or offer the flexibility of allowing users to analyze the code. Of course, I haven't read the paper yet. Maybe they take that into account.
Which is why they pay for good PR to cover their lousy licensing schemes.
Derek