I have about 15 years of time, experience and thousands in software invested in working with their platform(s).
First of all, I imagine at least a few hundred of those thousands are from things which simply aren't needed on other platforms. I'm talking about things like AppZapper here -- Apple has this community of shareware that just looks weird, coming from Windows and Linux.
Second, OS X hasn't been out 15 years. Since OS X, if your experience is more than skin deep, you know Unix. And I'm really not sure how much OS9 has in common with OS X, in terms of your skillset.
Finally, the stuff you have doesn't magically stop working, just because your next computer/gadget doesn't come from Apple.
Products I love from a company with some policies I hate is still a better than my other option: products I hate from a company I also hate.
This assumes you've completely abandoned a third option: products from no company at all.
It does look like Adobe has you by the balls, though, which isn't a good place to be.
I highly doubt that the departure of one geek would change anything.
Are you sure you're the only one thinking this?
A major cellphone provider in my area didn't support shortcodes for text messages. That's a serious feature, but they claimed they had never heard anyone ask for it before he called -- they didn't really know it existed.
So I would say, even if it is just one person, one person is better than none.
But "The 'done booting' time did not include bringing up the network"? Um, ok... no.
Consider that "bringing up the network" generally involves communicating with at least one other device. You can't really call it a metric of OS boot time when merely plugging into a different network (or none at all) might change the result.
Come to think of it, what people really need to do is take a good look at modern OSes and determine EXACTLY what still needs to be there and what's cruft.
I would much prefer simply cutting them out of the boot process, or making a smarter boot process.
For example: Maybe I do want a MySQL server running. But I certainly don't want you to delay my login screen while I wait for it to start. I probably don't want it eating up RAM on a desktop, either, until something needs it.
A good implementation: X11 on OS X. Granted, there are many things not to like about it, but one thing to love is the fact that it only starts once you actually attempt to run an X app.
We should be able to easily see who created the data, who says that person is legit, and whether the data has been tampered with.
You've just described SSL.
Granted, it's not about the files -- it's entirely up to the server to ensure which files are sent. But everything else you described is true about the server, so the only thing left is for the server to say whether it thinks the files are legit.
Then we don't have to worry about the network at all.
Not going to address the audacity of that statement itself, but I should point out:
If I'm viewing something which is signed by somebody with multiple governments or financial institutions also saying he is real and legit, I want my computer to tell me this guy is real and not a scammer.
You're talking about a web of trust, which is every bit as difficult to build and maintain as any other network.
OK you're of age to drive on the nation's interstate system. So we're not going to put up any speed limits or signs/signals/regulatory devices. It's every man for himself... good luck.
Most ISPs do, in fact, have (anti)spam policies, among other things. The signs, signals, and regulatory devices are there -- for the basic stuff.
But let me put this another way: In my state, Driver's Education is required. A quiz is also required to upgrade a learner's permit to a real license, once you're of age for one.
That's not always the case everywhere, but some basic competence is expected.
Then, once you're out there on the highway, it's pretty much every car for itself. If you get hit, sure, you might be able to sue the guy -- which also assumes he doesn't simply hit-and-run. Other than that, you have to deal with people being assholes every day, and you can't really trust anyone other than yourself to keep yourself from smacking into other people.
But, given your example below, it seems like the more fundamental problems on the Internet are even easier to solve than the fundamental problems on the road. You see, on the road, it might not be your fault -- someone else could actually crash into you. But on the Internet, if you fell for a phishing scheme, it's more like crashing into a telephone pole -- you've got no one to blame but yourself.
I'm all for putting banks and anything related to finances on a more-secure, separate network.
How, exactly, would it be more secure without educating end-users?
We already have SSL, with a few added layers of verification on top of that. If a user can't be bothered to so much as check a fucking URL, what makes you think they'll even know this other network exists?
And if they do, what makes you think the cute little BonziBuddy 2.0 (Now with MySpace!) crapware they installed won't grab their account info via a keylogger? What makes you think they'll know not to trust emails claiming to be from their bank -- given that many banks tell you not to trust such emails now?
Sorry, but protecting uneducated people from themselves is not enough to give up my freedoms. That's a bit like saying we can't have crayons in schools, because some kids like to eat them.
Easiest way: When installing Ubuntu, choose "Manual Partitioning", not "Guided Partitioning". Then, create whatever partitions you need -- you really only need one for the root partition, roughly equivalent to C: on Windows.
If you don't create a swap partition, you won't have a swap partition. End of story.
Simplest way I know of to check if that's working: run 'free' on the commandline. The bottom line, for Swap, should be three little zeroes.
If you've already installed, it's somewhat more complicated, as you now have to repartition. That's beyond the scope of a simple Slashdot post -- it's not terribly hard, but there's too many steps, and too many cases of "it depends".
The simplest way would be to edit/etc/fstab and remove any lines mentioning "swap", then reboot -- but this just tells Linux not to use the swap partition. It's still there, taking up space. And if you're already wasting space on it, you lose nothing by activating it -- Linux doesn't much use swap until it's out of RAM.
SSD's do not seem to be the best medium to hold swap partitios
I'm curious what the rationale for this is. I just got a shiny new Dell laptop with a 128 gig SSD, preloaded with Ubuntu, and it seems to have 4 gigs of swap. (Actually seems to be exactly as much swap as RAM.)
Where can I find a description of how this actually works?
They claim things like FUSE support, which makes no sense (a FUSE filesystem can be anything, and swsusp is supposed to suspend your running userspace apps, not leave them running).
And how would suspend-to-file work? I suppose if the file in question is not on a FUSE filesystem, and you flush everything but the filesystem first, it could work... or if you preallocate everything needed...
Aside from the inherent problems others are presenting, it seems trivially vulnerable to the porn site vulnerability.
That is: Setup a free porn site -- or a free site of any kind, with content people want to access, but it shouldn't be too hard to get enough porn together (original or pirated) to build a free porn site.
Then, require your users to solve the CAPTCHA (or reCAPTCHA) in order to get to the content. Unless your users are very observant, they probably won't realize that the CAPTCHA they're looking at isn't from you (or from your own reCAPTCHA account).
Even if this was no longer feasible, the fundamental problem is, people are cheap enough. CAPTCHA is therefore flawed in its very mission statement: Telling Computers and Humans Apart isn't enough anymore, unless you're going to do it on every single request, which would drive your users away.
I don't have a real solution for this. I know of a few hacks which would at least make it more difficult -- probably much more difficult than a CAPTCHA. But it's a much deeper problem than that. You'd have to design the system such that it's actually unattractive to spammers, even if they could game it -- and that is incredibly tricky to do, while still making it accessible to humans.
To spambots filling out HTML forms? For now, a few solutions:
WPoison (just because it actually wastes their resources if it works), probably disallowed by robots.txt, and probably setup to ban people who hit it too often.
Another interesting possibility is requiring Javascript, thus forcing the user to not only have an HTML engine (or a regex), but also a fully functional Javascript interpreter. Sure, they could target any one Javascript countermeasure, but they couldn't catch 'em all.
And to actual email spam in my inbox?
Probably both a tarpit (combined with banning people from the website) to cut down on bandwidth when I do catch one, and a statistical filter of some kind to help identify that.
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses ( ) Mailing lists and other legitimate email uses would be affected ( ) No one will be able to find the guy or collect the money ( ) It is defenseless against brute force attacks ( ) It will stop spam for two weeks and then we'll be stuck with it ( ) Users of email will not put up with it ( ) Microsoft will not put up with it ( ) The police will not put up with it ( ) Requires too much cooperation from spammers ( ) Requires immediate total cooperation from everybody at once ( ) Many email users cannot afford to lose business or alienate potential employers ( ) Spammers don't care about invalid addresses in their lists ( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it ( ) Lack of centrally controlling authority for email ( ) Open relays in foreign countries ( ) Ease of searching tiny alphanumeric address space of all email addresses (X) Asshats ( ) Jurisdictional problems ( ) Unpopularity of weird new taxes ( ) Public reluctance to accept weird new forms of money ( ) Huge existing software investment in SMTP ( ) Susceptibility of protocols other than SMTP to attack ( ) Willingness of users to install OS patches received by email ( ) Armies of worm riddled broadband-connected Windows boxes ( ) Eternal arms race involved in all filtering approaches ( ) Extreme profitability of spam ( ) Joe jobs and/or identity theft ( ) Technically illiterate politicians ( ) Extreme stupidity on the part of people who do business with spammers ( ) Dishonesty on the part of spammers themselves (X) Bandwidth costs that are unaffected by client filtering ( ) Outlook
and the following philosophical objections may also apply:
( ) Ideas similar to yours are easy to come up with, yet none have ever been shown practical ( ) Any scheme based on opt-out is unacceptable ( ) SMTP headers should not be the subject of legislation ( ) Blacklists suck ( ) Whitelists suck ( ) We should be able to talk about Viagra without being censored ( ) Countermeasures should not involve wire fraud or credit card fraud ( ) Countermeasures should not involve sabotage of public networks ( ) Countermeasures must work if phased in gradually ( ) Sending email should be free (X) Why should we have to trust you and your servers? ( ) Incompatiblity with open source or open source licenses ( ) Feel-good measures do nothing to solve the problem ( ) Temporary/one-time email addresses are cumbersome ( ) I don't want the government reading my email ( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
( ) Sorry dude, but I don't think it would work. ( ) This is a stupid idea, and you're a stupid person for suggesting it. ( ) Nice try, assh0le! I'm going to find out where you live and burn your house down!
Note two things:
Akismet actually does work, mostly. Huh. The Form isn't infallible, especially when it applies to things other than email.
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses (X) Mailing lists and other legitimate email uses would be affected ( ) No one will be able to find the guy or collect the money ( ) It is defenseless against brute force attacks ( ) It will stop spam for two weeks and then we'll be stuck with it (X) Users of email will not put up with it ( ) Microsoft will not put up with it (X) The police will not put up with it ( ) Requires too much cooperation from spammers (X) Requires immediate total cooperation from everybody at once (X) Many email users cannot afford to lose business or alienate potential employers ( ) Spammers don't care about invalid addresses in their lists ( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it ( ) Lack of centrally controlling authority for email ( ) Open relays in foreign countries ( ) Ease of searching tiny alphanumeric address space of all email addresses (X) Asshats ( ) Jurisdictional problems ( ) Unpopularity of weird new taxes ( ) Public reluctance to accept weird new forms of money ( ) Huge existing software investment in SMTP ( ) Susceptibility of protocols other than SMTP to attack ( ) Willingness of users to install OS patches received by email (X) Armies of worm riddled broadband-connected Windows boxes ( ) Eternal arms race involved in all filtering approaches ( ) Extreme profitability of spam ( ) Joe jobs and/or identity theft ( ) Technically illiterate politicians ( ) Extreme stupidity on the part of people who do business with spammers ( ) Dishonesty on the part of spammers themselves (X) Bandwidth costs that are unaffected by client filtering (X) Outlook
and the following philosophical objections may also apply:
(X) Ideas similar to yours are easy to come up with, yet none have ever been shown practical ( ) Any scheme based on opt-out is unacceptable ( ) SMTP headers should not be the subject of legislation ( ) Blacklists suck ( ) Whitelists suck ( ) We should be able to talk about Viagra without being censored ( ) Countermeasures should not involve wire fraud or credit card fraud ( ) Countermeasures should not involve sabotage of public networks (X) Countermeasures must work if phased in gradually ( ) Sending email should be free ( ) Why should we have to trust you and your servers? ( ) Incompatiblity with open source or open source licenses ( ) Feel-good measures do nothing to solve the problem ( ) Temporary/one-time email addresses are cumbersome ( ) I don't want the government reading my email ( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(X) Sorry dude, but I don't think it would work. ( ) This is a stupid idea, and you're a stupid person for suggesting it. ( ) Nice try, assh0le! I'm going to find out where you live and burn your house down!
First of all, stop calling it SPAM. It's not an acronym -- it's just named after the actual meat, used in a certain context.
But more importantly...
The most effective SPAM filter is a human, sitting in front of their e-mail client, deleting mail that they know is SPAM from the subject line.
Incorrect.
Firstly, I don't know about the rest of you, but I get far too much spam to read every subject line. It's already impractical, and getting to where it would be physically impossible without hiring people to read my email for me.
But also, a human is not necessarily the most accurate filter:
Granted, if you actually read every single email, rather than skimming through subject lines, you'd have a shot. But it's impractical, at this point, for me to even read subject lines. It's impossible for me to actually read the text of every single email.
In fact, that's why I use Bogofilter -- it's somewhat of a hybrid, that way. It uses reasonably sophisticated techniques to categorize spam, but it has an additional classification of "unsure". Last I checked, on any given day, I was getting maybe ten "unsure" messages to a hundred actual spams. There are quite often some false positives in unsure, and some that I'm not sure about myself. Most of it is spam, and I retrain it as such.
Net result: Roughly one or two messages per day make it through, and those come through Ruby Talk. Maybe once or twice a month, something will actually hit my inbox directly. And as far as I know, I've never had a false positive.
Aside from being very addictive -- and it included splitscreen on a PC, which is occasionally a very good idea -- it was also, for many years, the open source game with which to test your video card.
More recently, I use Nexuiz, but that's still what I remember it as. If you could run Armagetron fullscreen with decent settings, at least you know your video card is working. If you couldn't, chances are, you'd misconfigured something and thrown yourself into software mode.
The Roku Netflix player is a very different product.
And this is different how, software-wise?
These are all features which are hard to find on a MythTV box.
Since they are presumably building custom hardware, is there a particular reason MythTV wouldn't work on the box they built? If not, I say again, why did they bother?
I don't mean that they shouldn't have bothered releasing the hardware. I mean, why did they bother writing their own code, instead of using/forking/improving MythTV?
These never crash, hang, or act-up like PC devices often do (at least in my experience) and behave more like you would associate with an appliance.
In my experience, Linux boxes do not crash, hang, or act-up, with the possible exception of weird hardware and/or drivers. If you're building a box for the express purpose of being a Linux media center, and possibly writing your own drivers, this isn't an issue for you.
In other words, the difference is that MythTV can pull from cable, whereas this is designed to pull from the Internet.
In other words, they went and implemented their own, completely separate system, to avoid writing the equivalent of a YouTube client for MythTV. (And hey, I bet MythTV already supports YouTube.)
Nothing is stopping Google from turning these two applications into something better than Second Life.
Well, except that Second Life already exists, and Lively sucks balls compared to it.
Lively has no source code available, that I can find. The closest thing I could find has barely started to reverse engineer Lively, and appears to have no actual code written. And the official client is XP/Vista, IE/Firefox, nothing else.
Contrast this to Second Life, which has an open source client, with officially supported Windows/Mac/Linux versions.
From what other people are telling me, it doesn't get any better once you install -- crappy UI, and no real content creation for end-users.
Google easily could beat Second Life, if they wanted to. It's obvious from this pathetic attempt that they won't be doing so anytime soon.
One more thing, from TFA:
Over the long term, Hanna said that while he couldn't speak for Google's official stance, his hope is that Lively becomes "invisible" as much as Flash, Java or HTML are as the backbone of the web experience, that it becomes a "core architecture."
Ok, HTML and JavaScript are core achitectures. Java has a shot, being that it's now open source and reasonably mature.
But if they aspire to become another Flash, no thanks. Flash is cross-platform, at least, but proprietary, limited architectures (where's my 64-bit), slow as hell (Flash 10 will finally be hardware-accelerated), and poorly integrated (try right-clicking anywhere in Flash, vs anywhere in your browser).
That's a big advantage SL has: an interactive environment is a much more productive one.
Only if the interactive environment is of superior quality to the static environment.
It's like Smalltalk
Indeed. One of the curious things about Smalltalk is the lack of source code.
Maybe my ignorance is showing -- I gave up on Squeak when I couldn't make it run on 64-bit. I got interested later, and read up on the Smalltalk VM, which, as it turns out, makes all kinds of crazy assumptions and optimizations for 32-bit machines, with no thought given to true architecture independence.
All that aside, though... Oh yeah, source code. Turns out Smalltalk programs don't have any.
That is: There's nothing but the running program. There's excellent tools, included in your Smalltalk environment, for modifying the running program. But ultimately, if you want to share that program, you share a VM image.
Now, in theory, I suppose, this is superior. There are a lot of reasons I prefer this approach, philosophically -- and in theory, all of the drawbacks of this versus text are a result of text having more tools, currently.
But so far, languages like Ruby have proven easier. There's still irb to explore in -- or the python commandline, or Firebug for Javascript, etc -- but at the end of the day, I get to use Kate (or TextMate), Git (or SVN), rspec, Capistrano, and other tools which are fundamentally based on the idea of textual source code, in simple text files on the host OS.
That's what I think the comparison is here -- even if LSL is actually a decent language or environment (I wouldn't know), or if the other tools for building content are at all good, they can't compete with being able to pick just about any third party tool for managing source code (all the stuff I mentioned above), textures (Photoshop, Illustrator, or even Gimp), or models (Maya, 3DsMax, LightWave, whatever).
Disclaimer: I've never used Second Life, barely used Smalltalk, and never done any serious modelling. I don't actually know what I'm talking about, and I could be entirely wrong. Am I?
We're not talking drivers here, we're talking full apps that rely on a number of libraries, none of which are standard across the various platforms that use the linux kernel.
You can get close enough.
Anything capable of playing games -- or at least, playing games on Linux (PS3 is right out) -- is going to have something resembling OpenGL, maybe MiniGL.
Some locked-down set top boxes aside, if we're watching movies, it's going to be through xvideo. Sound will go through ALSA, and OpenAL will probably be on most of these platforms.
So, the standard combination of SDL + OpenGL + OpenAL + X11 is pretty solid across all desktop-like platforms, with the exception of embedded devices, which still probably have MiniGL.
In fact, games are perhaps the most portable apps. After the above, what's really left? The POSIX filesystem API? Networking? In other words, stuff Unix has had for decades... Everything else (zipfile support, mp3 decoders, model/level formats, etc) is generally linked in on Windows anyway. On Linux, you often even see things like windowing toolkits statically linked, because of that same Windows mentality.
Of course, many games sabotage this anyway, by using things like hand-optimized assembler. But I don't think most games need that -- and the ones that do, won't for very long. (Consider that the biggest change in most Doom source ports is rewriting the ASM in C, to make it portable, since the performance really doesn't matter anymore.)
The problem is 'policing' the content introduced to the system. In an open ended world like this it'd be trivial for someone to upload some malicious code. There'd have to be some sort of submission system where all code is reviewed before it's introduced to the system, but even that wouldn't be fool proof and it'd probably be pretty expensive.
That would never scale, and it would be absurdly restrictive if it did.
When are people going to realize that the Internet is successful because of its openness, not in spite of it?
Take a close look at Second Life, and consider two things: First, I believe they limited the damage of "malicious code" the same way a web browser does, by sandboxing it. And second, it's actually pretty slow and horrible, I would guess mostly because of the fact that it's still based on a bigass-central-server model. Granted, they are starting to work with whatever IBM's project was, but there's still nothing like the simplest scaling tool the web gave us -- the hyperlink.
Unfortunately, the only other attempts at building something similar are all stuck in alpha-ish states, with very little (visible) development, and pretty much no cohesion.
Slashdot Mirror
Touche, but I would much sooner learn SmallTalk than go through the pain of attempting Java again.
I have about 15 years of time, experience and thousands in software invested in working with their platform(s).
First of all, I imagine at least a few hundred of those thousands are from things which simply aren't needed on other platforms. I'm talking about things like AppZapper here -- Apple has this community of shareware that just looks weird, coming from Windows and Linux.
Second, OS X hasn't been out 15 years. Since OS X, if your experience is more than skin deep, you know Unix. And I'm really not sure how much OS9 has in common with OS X, in terms of your skillset.
Finally, the stuff you have doesn't magically stop working, just because your next computer/gadget doesn't come from Apple.
Products I love from a company with some policies I hate is still a better than my other option: products I hate from a company I also hate.
This assumes you've completely abandoned a third option: products from no company at all.
It does look like Adobe has you by the balls, though, which isn't a good place to be.
I highly doubt that the departure of one geek would change anything.
Are you sure you're the only one thinking this?
A major cellphone provider in my area didn't support shortcodes for text messages. That's a serious feature, but they claimed they had never heard anyone ask for it before he called -- they didn't really know it existed.
So I would say, even if it is just one person, one person is better than none.
But "The 'done booting' time did not include bringing up the network"? Um, ok... no.
Consider that "bringing up the network" generally involves communicating with at least one other device. You can't really call it a metric of OS boot time when merely plugging into a different network (or none at all) might change the result.
Come to think of it, what people really need to do is take a good look at modern OSes and determine EXACTLY what still needs to be there and what's cruft.
I would much prefer simply cutting them out of the boot process, or making a smarter boot process.
For example: Maybe I do want a MySQL server running. But I certainly don't want you to delay my login screen while I wait for it to start. I probably don't want it eating up RAM on a desktop, either, until something needs it.
A good implementation: X11 on OS X. Granted, there are many things not to like about it, but one thing to love is the fact that it only starts once you actually attempt to run an X app.
We should be able to easily see who created the data, who says that person is legit, and whether the data has been tampered with.
You've just described SSL.
Granted, it's not about the files -- it's entirely up to the server to ensure which files are sent. But everything else you described is true about the server, so the only thing left is for the server to say whether it thinks the files are legit.
Then we don't have to worry about the network at all.
Not going to address the audacity of that statement itself, but I should point out:
If I'm viewing something which is signed by somebody with multiple governments or financial institutions also saying he is real and legit, I want my computer to tell me this guy is real and not a scammer.
You're talking about a web of trust, which is every bit as difficult to build and maintain as any other network.
Warning: Automotive analogies.
OK you're of age to drive on the nation's interstate system. So we're not going to put up any speed limits or signs/signals/regulatory devices. It's every man for himself... good luck.
Most ISPs do, in fact, have (anti)spam policies, among other things. The signs, signals, and regulatory devices are there -- for the basic stuff.
But let me put this another way: In my state, Driver's Education is required. A quiz is also required to upgrade a learner's permit to a real license, once you're of age for one.
That's not always the case everywhere, but some basic competence is expected.
Then, once you're out there on the highway, it's pretty much every car for itself. If you get hit, sure, you might be able to sue the guy -- which also assumes he doesn't simply hit-and-run. Other than that, you have to deal with people being assholes every day, and you can't really trust anyone other than yourself to keep yourself from smacking into other people.
But, given your example below, it seems like the more fundamental problems on the Internet are even easier to solve than the fundamental problems on the road. You see, on the road, it might not be your fault -- someone else could actually crash into you. But on the Internet, if you fell for a phishing scheme, it's more like crashing into a telephone pole -- you've got no one to blame but yourself.
I'm all for putting banks and anything related to finances on a more-secure, separate network.
How, exactly, would it be more secure without educating end-users?
We already have SSL, with a few added layers of verification on top of that. If a user can't be bothered to so much as check a fucking URL, what makes you think they'll even know this other network exists?
And if they do, what makes you think the cute little BonziBuddy 2.0 (Now with MySpace!) crapware they installed won't grab their account info via a keylogger? What makes you think they'll know not to trust emails claiming to be from their bank -- given that many banks tell you not to trust such emails now?
Sorry, but protecting uneducated people from themselves is not enough to give up my freedoms. That's a bit like saying we can't have crayons in schools, because some kids like to eat them.
Easiest way: When installing Ubuntu, choose "Manual Partitioning", not "Guided Partitioning". Then, create whatever partitions you need -- you really only need one for the root partition, roughly equivalent to C: on Windows.
If you don't create a swap partition, you won't have a swap partition. End of story.
Simplest way I know of to check if that's working: run 'free' on the commandline. The bottom line, for Swap, should be three little zeroes.
If you've already installed, it's somewhat more complicated, as you now have to repartition. That's beyond the scope of a simple Slashdot post -- it's not terribly hard, but there's too many steps, and too many cases of "it depends".
The simplest way would be to edit /etc/fstab and remove any lines mentioning "swap", then reboot -- but this just tells Linux not to use the swap partition. It's still there, taking up space. And if you're already wasting space on it, you lose nothing by activating it -- Linux doesn't much use swap until it's out of RAM.
SSD's do not seem to be the best medium to hold swap partitios
I'm curious what the rationale for this is. I just got a shiny new Dell laptop with a 128 gig SSD, preloaded with Ubuntu, and it seems to have 4 gigs of swap. (Actually seems to be exactly as much swap as RAM.)
Where can I find a description of how this actually works?
They claim things like FUSE support, which makes no sense (a FUSE filesystem can be anything, and swsusp is supposed to suspend your running userspace apps, not leave them running).
And how would suspend-to-file work? I suppose if the file in question is not on a FUSE filesystem, and you flush everything but the filesystem first, it could work... or if you preallocate everything needed...
Aside from the inherent problems others are presenting, it seems trivially vulnerable to the porn site vulnerability.
That is: Setup a free porn site -- or a free site of any kind, with content people want to access, but it shouldn't be too hard to get enough porn together (original or pirated) to build a free porn site.
Then, require your users to solve the CAPTCHA (or reCAPTCHA) in order to get to the content. Unless your users are very observant, they probably won't realize that the CAPTCHA they're looking at isn't from you (or from your own reCAPTCHA account).
Even if this was no longer feasible, the fundamental problem is, people are cheap enough. CAPTCHA is therefore flawed in its very mission statement: Telling Computers and Humans Apart isn't enough anymore, unless you're going to do it on every single request, which would drive your users away.
I don't have a real solution for this. I know of a few hacks which would at least make it more difficult -- probably much more difficult than a CAPTCHA. But it's a much deeper problem than that. You'd have to design the system such that it's actually unattractive to spammers, even if they could game it -- and that is incredibly tricky to do, while still making it accessible to humans.
To which problem?
To spambots filling out HTML forms? For now, a few solutions:
WPoison (just because it actually wastes their resources if it works), probably disallowed by robots.txt, and probably setup to ban people who hit it too often.
Another interesting possibility is requiring Javascript, thus forcing the user to not only have an HTML engine (or a regex), but also a fully functional Javascript interpreter. Sure, they could target any one Javascript countermeasure, but they couldn't catch 'em all.
And to actual email spam in my inbox?
Probably both a tarpit (combined with banning people from the website) to cut down on bandwidth when I do catch one, and a statistical filter of some kind to help identify that.
Your post advocates a
(X) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
( ) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
( ) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
(X) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
(X) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
( ) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
(X) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
( ) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your
house down!
Note two things:
Akismet actually does work, mostly. Huh. The Form isn't infallible, especially when it applies to things other than email.
And, all plans fail to account for asshats.
Yeah, I used to think that was a good idea...
Your post advocates a
(X) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
(X) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
(X) Users of email will not put up with it
( ) Microsoft will not put up with it
(X) The police will not put up with it
( ) Requires too much cooperation from spammers
(X) Requires immediate total cooperation from everybody at once
(X) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
(X) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
(X) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
(X) Bandwidth costs that are unaffected by client filtering
(X) Outlook
and the following philosophical objections may also apply:
(X) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
(X) Countermeasures must work if phased in gradually
( ) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(X) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your
house down!
ctrl+c. ctrl+v.
Or you can find the definitive version here.
First of all, stop calling it SPAM. It's not an acronym -- it's just named after the actual meat, used in a certain context.
But more importantly...
The most effective SPAM filter is a human, sitting in front of their e-mail client, deleting mail that they know is SPAM from the subject line.
Incorrect.
Firstly, I don't know about the rest of you, but I get far too much spam to read every subject line. It's already impractical, and getting to where it would be physically impossible without hiring people to read my email for me.
But also, a human is not necessarily the most accurate filter:
http://www.paulgraham.com/wsy.html
Granted, if you actually read every single email, rather than skimming through subject lines, you'd have a shot. But it's impractical, at this point, for me to even read subject lines. It's impossible for me to actually read the text of every single email.
In fact, that's why I use Bogofilter -- it's somewhat of a hybrid, that way. It uses reasonably sophisticated techniques to categorize spam, but it has an additional classification of "unsure". Last I checked, on any given day, I was getting maybe ten "unsure" messages to a hundred actual spams. There are quite often some false positives in unsure, and some that I'm not sure about myself. Most of it is spam, and I retrain it as such.
Net result: Roughly one or two messages per day make it through, and those come through Ruby Talk. Maybe once or twice a month, something will actually hit my inbox directly. And as far as I know, I've never had a false positive.
Aside from being very addictive -- and it included splitscreen on a PC, which is occasionally a very good idea -- it was also, for many years, the open source game with which to test your video card.
More recently, I use Nexuiz, but that's still what I remember it as. If you could run Armagetron fullscreen with decent settings, at least you know your video card is working. If you couldn't, chances are, you'd misconfigured something and thrown yourself into software mode.
If not, why don't they just sell a MythTV box?
The Roku Netflix player is a very different product.
And this is different how, software-wise?
These are all features which are hard to find on a MythTV box.
Since they are presumably building custom hardware, is there a particular reason MythTV wouldn't work on the box they built? If not, I say again, why did they bother?
I don't mean that they shouldn't have bothered releasing the hardware. I mean, why did they bother writing their own code, instead of using/forking/improving MythTV?
These never crash, hang, or act-up like PC devices often do (at least in my experience) and behave more like you would associate with an appliance.
In my experience, Linux boxes do not crash, hang, or act-up, with the possible exception of weird hardware and/or drivers. If you're building a box for the express purpose of being a Linux media center, and possibly writing your own drivers, this isn't an issue for you.
Can anyone comment on MythTV's stability?
Except, doesn't MythTV already have a frontend client?
Given that, I ask again, why did they bother?
In other words, the difference is that MythTV can pull from cable, whereas this is designed to pull from the Internet.
In other words, they went and implemented their own, completely separate system, to avoid writing the equivalent of a YouTube client for MythTV. (And hey, I bet MythTV already supports YouTube.)
Linus originally used Minix as a development platform for Linux.
Right... What's your point?
I don't mean to be confrontational there, but I actually don't get it. Linus used Minix to bootstrap Linux development. What does that prove?
Nothing is stopping Google from turning these two applications into something better than Second Life.
Well, except that Second Life already exists, and Lively sucks balls compared to it.
Lively has no source code available, that I can find. The closest thing I could find has barely started to reverse engineer Lively, and appears to have no actual code written. And the official client is XP/Vista, IE/Firefox, nothing else.
Contrast this to Second Life, which has an open source client, with officially supported Windows/Mac/Linux versions.
From what other people are telling me, it doesn't get any better once you install -- crappy UI, and no real content creation for end-users.
Google easily could beat Second Life, if they wanted to. It's obvious from this pathetic attempt that they won't be doing so anytime soon.
One more thing, from TFA:
Over the long term, Hanna said that while he couldn't speak for Google's official stance, his hope is that Lively becomes "invisible" as much as Flash, Java or HTML are as the backbone of the web experience, that it becomes a "core architecture."
Ok, HTML and JavaScript are core achitectures. Java has a shot, being that it's now open source and reasonably mature.
But if they aspire to become another Flash, no thanks. Flash is cross-platform, at least, but proprietary, limited architectures (where's my 64-bit), slow as hell (Flash 10 will finally be hardware-accelerated), and poorly integrated (try right-clicking anywhere in Flash, vs anywhere in your browser).
That's a big advantage SL has: an interactive environment is a much more productive one.
Only if the interactive environment is of superior quality to the static environment.
It's like Smalltalk
Indeed. One of the curious things about Smalltalk is the lack of source code.
Maybe my ignorance is showing -- I gave up on Squeak when I couldn't make it run on 64-bit. I got interested later, and read up on the Smalltalk VM, which, as it turns out, makes all kinds of crazy assumptions and optimizations for 32-bit machines, with no thought given to true architecture independence.
All that aside, though... Oh yeah, source code. Turns out Smalltalk programs don't have any.
That is: There's nothing but the running program. There's excellent tools, included in your Smalltalk environment, for modifying the running program. But ultimately, if you want to share that program, you share a VM image.
Now, in theory, I suppose, this is superior. There are a lot of reasons I prefer this approach, philosophically -- and in theory, all of the drawbacks of this versus text are a result of text having more tools, currently.
But so far, languages like Ruby have proven easier. There's still irb to explore in -- or the python commandline, or Firebug for Javascript, etc -- but at the end of the day, I get to use Kate (or TextMate), Git (or SVN), rspec, Capistrano, and other tools which are fundamentally based on the idea of textual source code, in simple text files on the host OS.
That's what I think the comparison is here -- even if LSL is actually a decent language or environment (I wouldn't know), or if the other tools for building content are at all good, they can't compete with being able to pick just about any third party tool for managing source code (all the stuff I mentioned above), textures (Photoshop, Illustrator, or even Gimp), or models (Maya, 3DsMax, LightWave, whatever).
Disclaimer: I've never used Second Life, barely used Smalltalk, and never done any serious modelling. I don't actually know what I'm talking about, and I could be entirely wrong. Am I?
We're not talking drivers here, we're talking full apps that rely on a number of libraries, none of which are standard across the various platforms that use the linux kernel.
You can get close enough.
Anything capable of playing games -- or at least, playing games on Linux (PS3 is right out) -- is going to have something resembling OpenGL, maybe MiniGL.
Some locked-down set top boxes aside, if we're watching movies, it's going to be through xvideo. Sound will go through ALSA, and OpenAL will probably be on most of these platforms.
So, the standard combination of SDL + OpenGL + OpenAL + X11 is pretty solid across all desktop-like platforms, with the exception of embedded devices, which still probably have MiniGL.
In fact, games are perhaps the most portable apps. After the above, what's really left? The POSIX filesystem API? Networking? In other words, stuff Unix has had for decades... Everything else (zipfile support, mp3 decoders, model/level formats, etc) is generally linked in on Windows anyway. On Linux, you often even see things like windowing toolkits statically linked, because of that same Windows mentality.
Of course, many games sabotage this anyway, by using things like hand-optimized assembler. But I don't think most games need that -- and the ones that do, won't for very long. (Consider that the biggest change in most Doom source ports is rewriting the ASM in C, to make it portable, since the performance really doesn't matter anymore.)
the choice to use an operating system with a marginal market share not likely to get commercial support!
You mean like the support I just got from Dell for my shiny new Ubuntu laptop?
The problem is 'policing' the content introduced to the system. In an open ended world like this it'd be trivial for someone to upload some malicious code. There'd have to be some sort of submission system where all code is reviewed before it's introduced to the system, but even that wouldn't be fool proof and it'd probably be pretty expensive.
That would never scale, and it would be absurdly restrictive if it did.
When are people going to realize that the Internet is successful because of its openness, not in spite of it?
Take a close look at Second Life, and consider two things: First, I believe they limited the damage of "malicious code" the same way a web browser does, by sandboxing it. And second, it's actually pretty slow and horrible, I would guess mostly because of the fact that it's still based on a bigass-central-server model. Granted, they are starting to work with whatever IBM's project was, but there's still nothing like the simplest scaling tool the web gave us -- the hyperlink.
Unfortunately, the only other attempts at building something similar are all stuck in alpha-ish states, with very little (visible) development, and pretty much no cohesion.