I see no problem with some corporation being associated with the project. If there are reasonable rules, and if the project has a reasonably open governance, corporate help is welcome.
To an extent it's fine, but the corporation usually ends up steering the project to some extent. For instance is Ubuntu more community-driven or Cononical driven?
Since it is open source, we can always fork it. And normally the fear of forks will stop the corporation from acting too badly - doing evil to open source software does not pay.
In the case of Canonical, we have an additional assurance: it is a private company, which does not have a fiduciary duty to maximize profits. It was founded by Mark Shuttleworth, who is a nice guy and was a Debian Developer.
Yes, I met him in person during DebConf10. Very friendly guy; I saw his talk on the Unity interface. I think the Debian developers have sort of an interesting like(--)standoffish relationship with Mark Shuttleworth. My impression was that he's well respected in the Debian community at the same time that many wish his efforts were in Debian rather than Ubuntu. [Nobody actually voiced this though.]
In the case of Ubuntu, the "evil" was selecting Unity as default. However, Xfce, LXDE, KDE and others are still available, and they are working on GNOBuntu (with the full Gnome, including the Gnome Shell). Despite the hate you see on Slashdot, Ubuntu is still the number 1 distribution - see http://en.wikipedia.org/wiki/Ubuntu_(operating_system)#Installed_base.
And, personally, I use Unity and like it just fine.
On http://distrowatch.com/ Ubuntu is #2 behind Linux Mint. Mint has two versions, one based on Ubuntu and one based on Debian -- and I believe it's the one based on Ubuntu that is most popular, which comes with either MATE, Cinnamon (Gnome2-like interface), KDE, or Xfde. Since Mint 13 is most popular, it's clear that many others don't like the Unity interface.:-P [So in effect I agree with you, just in a slightly different way.]
X is pretty huge and I'll bet it didn't just do the drivers you need but all of X - then there's KDE and a pile of apps there, I'll bet openoffice was in there too, so it comes down to Gentoo not being fine grained enough to cope with that situation with the options you told it to do (or not clearly telling you the consequences of your choices).
I followed http://www.gentoo.org/doc/en/xorg-config.xml and I decided to use 'emerge -pv xorg-drivers'. I was not able to get X to start afterwards. Not a big deal; I ended up using ssh and X forward to do the testing I needed to do. If I was really interested in running Gentoo I probably would have created an xorg.conf file in/etc/X11 and manually set the video driver to either vesa or vmware, but after three days of compiling I was impatient to get the testing I needed to do over with.:-P
I've been there, done that with a little slow fanless VIA system that could actually benefit from specific compiler flags so Gentoo actually made some difference, and it was more than one day to get what I wanted even though I didn't go overboard and went for fluxbox instead of gnome or kde. Package management is there in all the other distros to avoid such annoyances and in most cases the stuff is compiled to take full advantage of whatever CPU you have anyway. It should have said on the tin that Gentoo is all about insanely long compiles, but it's there in the docs if you look hard enough (eg. instructions on cross compilation for older hardware imply that it's going to take a very long time, so it gives you the option to do stuff on another faster machine instead). I played with it for a bit but that little slow box has Fedora on it now and a only a few things I've put on from source are actually optimised for that CPU. When you think about it the only times you really care about what the CPU is doing is in a very small number of appications that run it flat out and not the kernel, not X and not the window manager. Just compile gimp, vlc, firefox or whatever to use the hardware as well as it can run and you'd probably get all of the benefits of Gentoo on odd hardware, and if it's not odd hardware they'll just be a binary package that will do it just as well for you anyway.
The three-day compile was in a VirtualBox VM using both cores of a 2.5 GHz Core2Duo with 1024 MB of RAM dedicated to the VM. There's an irony in running Gentoo in that the reason given to run it is "speed", but to get that speed requires lots of compiling, which is slow.
There must be a way of installing pre-build binaries with Gentoo, as I've heard rumor of it, but I didn't find it myself. Probably a command-line switch to 'emerge'. If I end up running Gentoo again I'll try to figure that out.;-)
"Anytime the USE flags get updated Gentoo wants you to 'emerge @world' to recompile the whole system again..."
No, you'll just need to recompile the packages affected by the USE flag changes:
emerge --newuse --deep @world
Ah. Okay -- on that I stand corrected, then -- and I appologize for propagating misinformation. Thanks.
If you're building Chromium, or OO.Org from source on hardware built five years ago, system updates in Gentoo are a bit slow. But, Gentoo is fantastic for doing dev work. More often than not, I'll find that "apt-get build-deps" (or whatever it is that installs the *-dev packages that are required to build a package in the tree from source) just doesn't work. In gentoo: "emerge --only-deps $PACKAGE" *always* works.:)
Debian these days uses an automated build system; part of the reason is to catch issues where "apt-get build-dep (package)" doesn't pull in all of the required "-dev" development packages required to build the source package. This was done because otherwise there were too many "FTBFS" (Fails To Build From Source) problems like you're describing. IIRC I think this might have been something Ubuntu did first and then Debian picked up on sometime later.
The "figuring out which -dev packages to install" is still an issue for normal non-Debian source compiles, though. BTW if you end up using a Debian box for development again sometime, check out the 'checkinstall' package, as what it does is interesting. In the "normal" manual software installation steps of 1)./configure 2) make 3) make install, you just change step 3 to "checkinstall make install" and what checkinstall does is make a fake Debian package containing the list of files that were installed, so that dpkg won't trample them.:-)
. IMHO the best feature Debian has is the ability to upgrade-in-place -- so you never have to do a reinstall to keep it up-to-date unless you want to.
Indeed, I have installations of Debian that are 13 years old. They've been through multiple hardware revisions, and are now virtualized, but apt-get dist-upgrade has done the trick all this time.
However, technical achievements aside, it's Debian's policy that's the real star.
For the most part I agree concerning Policy, but there are lots of niche areas that Policy doesn't currently cover. To give you an idea of what I mean, there's a whole lot of discussion going on right now on [debian-devel] concerning:
- packages with same binary names in different directories [/usr/sbin vs/usr/bin]
- possibly merging/bin with/usr/bin, possibly merging/sbin with/usr/sbin
- policy issues concerning different init systems [file-rc, systemd, upstart, openrc]
- issues with who gets to choose what the default desktop environment will be
So Debian's Policy covers a lot, but there's still enough wiggle room in it that vigorous debates on lots of such topics are commonplace, and these end up changing Policy some. As a "normal user" we end up seeing the results as sweeping changes that comes down, like the switch from devfs to udev.
So rather than put my faith in Policy, generally I put my faith in "the Debian people". Because the excellent results are due to the efforts of the developers themselves, rather than due solely to the Policy that they work under.;-)
The wheezy installation I ran two weeks ago told me that I needed two binary non-free packages and asked if I wanted to load them from another device. I didn't try it though because I installed via a wired network.
It was probably related to Wireless hardware; the base Debian install these days ships only "free software", so by default you only get the package "firmware-linux-free" that contains firmware for 20 or so devices. Most of the firmware required to run Wireless cards are binary-only blobs that are considered "nonfree" in that you cannot see the source code for them, so that's why they're in the "non-free" section and don't come with the base install. [This is where Debian developers are purists, but I think it's for good reason.]
This can be frustrating if you're trying to do a network install over a Wireless card, which is why the option exists to load them from another device like a USB stick. Presumably you'd use another computer and download the necessary firmware and put it on a USB stick after finding it on http://packages.debian.org/ in the "Kernels" area.
Re:What is the problem with corporate help?
on
Happy Birthday, Debian!
·
· Score: 4, Interesting
It's one of the very few distros that are based solely on donations and have no private corporation behind them.
I see no problem with some corporation being associated with the project. If there are reasonable rules, and if the project has a reasonably open governance, corporate help is welcome.
To an extent it's fine, but the corporation usually ends up steering the project to some extent. For instance is Ubuntu more community-driven or Cononical driven? Is Fedora community-driven, or is it a platform for developing RHEL? What about Oracle? For instance when I think of Ubuntu, I ask the question "Who made the choice of the 3D Unity interface? Was it the community or was it Cononical?"
Corporations often have different needs than a home user does. Debian, for instance, contains a bunch of niche packages like those used by Amateur Radio operators. These are things you're not likely to see in an "Enterprise" distribution. So what you get as a user does differ depending on who is directing the distribution development. This doesn't make choosing an "Enterprise" distribution wrong of course -- it might be what you need.
It doesn't sound like you really know how to use gentoo based on what you're saying. I've built KDE and a system from scratch and it doesn't take one day let alone three.
Also, don't set USE flags system wid unless you know you want to, that's what/etc/portage/package.use is for.
See the link above; the instructions has one change the USE flags, and then has one run 'emerge -uDNav world'.
You're correct that the USE flag was --newuse and not --newuser. Your comment otherwise was quite rude. Surely using elitism isn't going to help the Gentoo project.
I suppose that it's long past time that I installed Debian. I've fought through Gentoo army of config files, gone through RPM hell with Red Hat and Mandrake, hacked at the jungle thicket of Fedora and swam in the cool waters of Arch. I've tried two Debian-based distributions, but never install Debian. Does it offer any real advantage over Arch?
Just recently I tried the top 25 free software distributions [as measured by distrowatch.com], one of which was Arch. I have to say Arch was one of the distros I found fun to play with -- the only thing I think is missing is a simple graphical installer. The first set of instructions I found on the Arch website weren't complete concerning the Grub2 install, leading to install and bootup failures, but the "Beginner's Guide" has complete instrcutions for the install. Package installation under arch is super fast. I couldn't get audio working in the VM I was installing it in, but other than that I really liked it.
And I tried Gentoo as well, and I found it just as hateful as I found it in 2003, if not more so. The "install", or shoud I say the compile, took three solid days to install a base system + a base install of KDE 4.8. The 'emerge' command often ran into dependency hell, forcing the use of several switches like 'emerge --newuser --update --deep (package)'. Anytime the USE flags get updated Gentoo wants you to 'emerge @world' to recompile the whole system again, and of course the instructions for intalling KDE4 has you modify the USE flags. I really do love a lot of the documentation I can get from the Gentoo project, but in terms of running it as a distro I want to keep it as far away from me as I can, because frankly I think it's insane.
Debian has a graphical installer, and you can choose several Desktop Environments right at the very start of the install menu. I think it's the only distro (or one of very few) that shows all of the choices of languages in their own native written language rather than the list being all in English. Debian is also the basis for a long list of other distros -- out of the top 25, 12 are Debian derivatives. IMHO the best feature Debian has is the ability to upgrade-in-place -- so you never have to do a reinstall to keep it up-to-date unless you want to. Debian has a lot of developer support behind the project, most of whom are free software purists -- which is generally a good thing. It's one of the very few distros that are based solely on donations and have no private corporation behind them. If you want to know more about Debian, my first suggestion is to watch an intro video given by Bdale Garbee from DebConf11 which I think was well spoken and informative: http://penta.debconf.org/dc11_schedule/events/804.en.html
I don't know enough about Arch to give a fair comparison between it and Debian; all I can say for the moment is that I've been running Debian for 13 years, and that in the very limited time I've spent with Arch I've been impressed with it.
The distributions I liked in testing them: Linux Mint Debian, Fedora 17, openSuSE, Debian, Arch, Pear Linux 5 (appearance of Mac OS X), SnowLinux 2 "Ice", and the DVD version of Knoppix 7.03. Distros I did not like: Ubuntu 12.04 (3D, Unity GUI), Mageia 2, PCLinuxOS (only "rpm" lines in/etc/apt/sources.list), Ultimate 3.4 (3D), Gentoo (insane long compiles), Fuduntu (yucky package installer), SolusOS (yucky package installer).
Concerning letters of recommendation: they do not have to come from professors or from a boss. When I went back for my MSEE, I used letters of recommendation from two colleagues and one from a friend. If letters specifically need to come from someone you've worked for then that will be stated in the requirements for entry from the particular graduate school you apply for.
You'll need to get official transcripts from each of the colleges you've attended. Typically these are required to come in envelopes with a signature over the seal. I suggest ordering an extra copy from each school for your own records. [This is mostly "just a good idea", but there are cases where schools have lost their records. The University of New Orleans, for instance, lost my sister's academic records there after the school was flooded during hurricanes Katrina back in 2005.]
The next thing you'll need to do is take the Graduate Record Exam (GRE). Having taken it I'll give you the following advice: concerning the Quantitative section what you most need to know is if you can answer each question you're given in less than 2 minutes. The computerized version of the test also does not allow you to go back and change your answers, because the test is adaptive -- the questions get harder as you answer lower questions correctly. Harder questions are also worth more points, so it's very important to answer the lower questions correctly in order to get to the harder ones. The paper-based GRE exam doesn't have these issues, if these are still being offered. In the Verbal section of the GRE, if possible be creative in your essay writing. At the end of the GRE exam you're asked what schools you want your GRE scores to be transmitted to (after you're told what they are right then and there, except for the essay section), so you should know what schools you're planning to apply to beforehand.
Your transcripts and letters of recommendation are generally given to the school with your application. The GRE scores are transmitted directly to the school.
All I can do is express my confusion. Nokia purchased Qt presumably with the intent of using it on their phones. They put out a couple of very good phones such as the N900 that leveraged Debian and Qt. All of that seemed like they were on the right path. Debian users practically swear by the N900.
And then... they announce plans to switch to a non-existent Windows platform. What? That was a total reversal of course away from what was previously a direction of free and open source software. Somewhere in the company I'm betting the reasoning given has to do with a spreadsheet of expected costs of development between the Qt and Windows platforms, and my personal bets are on those numbers being wrong and thus the wrong decision being made.
What matters to me personally is that Qt support structure survives this intact, because it's a very important framework. Thankfully Qt is GPL software, so the existing code will survive no matter what.
I don't suppose you have a reference source for this?
I found a reference, but it seems to indicate that the length of time the various providers store location information is shorter than I had remembered.
The cellular network has to know where you are to route calls to you. Back when they first came out, someone published an article about using cellular information to locate a person with his cell phone to within 36 feet.
Yes... additionally, last I recall this information is saved for a period of 7 years, which means not only does the phone system know where you are now, but it also knows where you've been. This means that you can be profiled based on the places you go, and thus there's a chance someone can predict where you're going to be at any given time.
93 deg F now, a week ago it hit 97 deg F for three days. No major power outages in the area. We have not run A/C at all yet. (We have one small window A/C unit if we get desperate.)
Our basic strategy is to open the windows at night an run fans, and turn the fans off and close the windows (and storm windows) at 7am. Our house seems to be insulated well enough that it stays cooler indoors than outdoors most of the day. Open windows and use fans again at 8pm. If it gets too hot, opt for showering in cool water -- this requires power because we have well water rather than municipal water.
Come on folks, of course I know who Linus is. Sheesh. Do I gotta put a smiley every time? (Apparently some people got it).
I realized it afterwards when I noticed the post was modded as Funny.:-P [As such -- sorry for the unnecessary reply.] Thing is, some people really are just that... er... "uninformed".
I don't know who this "Linus" guy think he is. Just because his name looks kinda similar to "Linux" doesn't mean he has the right to be jerk. The community should flame him off the forums because he apparently doesn't understand the open source ethos.
I notice that you didn't say he's wrong. And he openly admits he's strongly opinionated.
If he was a real programmer he'd just dig into the code and fix these problems.
He is, and he has -- simply as an example, he sent in patches to Gnome back when he complained about the lack of mouse configuration. But there's only a certain amount of this that is reasonable. Sending in a patch for a tweak can be expected -- sending in a patch to fix major design decisions is definitely not.
You can turn Nepomuk OFF. Unfortunately, Akonadi is another story. [more below]
We're a Linux shop with around 400 desktops and have been running KDE for a decade. KDE3 was rock solid. KDE4, not so much. The KDE4 direction of "let's index everything" with nepomuk and akonadi doesn't work so well when home directories are NFS mounted. In fact, it killed our fileserver. Further, why on earth would I want 400 instances of mysql_community_server running and creating a 128MB DB for each user in their home directory just to index their PIM?
I don't blame you one big for moving to XFCE; AFAIC it's the next-best alternative to KDE4. You're probably set with XFCE for the near future, but I'll point out the following in case in the future you retest KDE4.
Nepomuk can be turned off (on a per-user basis) by going to K->System Settings and then Workspace Appearance -> Desktop Search and turning off both the "Strigi Desktop File Indexer" and also "Nepomuk Semantic Desktop". Performance for Strigi indexing is still awful even on a local disk, let alone NFS, so I regularly turn these both completely off. Nepomuk still needs to be turned off IMHO, otherwise the Virtuoso database backing it slowly grows as you use the system. It isn't easy to find exactly what this does and what use you can make of it, but the following is a good resource that explains it:
Unfortunately Akonadi cannot be completely turned off AFAIK -- and what's sad is that (as you correctly pointed out) it does not store information, but rather only indexes PIM information. By default Akonadi has a dependency on MySQL, and EACH user that logs in requires starting a dedicated instance of MySQL server. That's a huge WTF right there. However -- you can reconfigure Akonadi (on a per-user basis) to use SQLite instead of MySQL in.config/akonaki/akonadiserverrc. But another WTF is that this has to be set up on a per-user basis. Apparently at one time there was a server-wide setting available, but if it exists today in KDE 4.8 I'm unable to find it or even a reference to it.:-/
With Nepomuk turned completely off and Akonadi set up to use SQLite, KDE4 is performs much better. Unfortunately there are certain things that Akonadi apparently cannot store in SQLite, so supposedly there can be issues with using it, but in practice I haven't run into any of them.
VLC works for about 90% of the DVDs and videos I'll download off the Internet. It works well enough for me, well enough that I haven't needed to use WMP to play a video in a long long time.
IMHO, not only does VLC work just as well as Windows Media Player for Vista, but I find it's actually preferrable to WMP.... so much so that I uninstalled WMP entirely. And like you, I've yet to find a DVD that VLC won't play.
The only thing with VLC is I have to remember to reconfigure it so that the mouse scroll button scrolls the time index of the media rather than the volume.
Adding to this, Netstumbler can't even capture data as its hopping channels. The only way to accomplish this if the author wrote another program that used another wireless card to sniff on the selected channel, which seems highly unlikely. If word got out what software Google was doing to accomplish this, wouldn't you think it would inspire someone to find ways to break it when a Google car is in your neighborhood? Presuming of course, they simply turned off the pcap capturing and continue to use it.
Interesting -- NetStumbler sounds like a very different tool than Kismet is. Concerning the packet sniffing Google did, my understanding is that the main issue was sniffing and storing of unencrypted packets, so yes, that would generally be easy to fix by turning encryption on. My understanding is that Google was likely mostly interested in sniffing and storing the SSIDs of access points along with GPS data on where they were located, and context like whether the AP was encrypted. In other words, they were essentially "war driving" while collecting map data. I don't think they had any ill intent, and likely just forgot to turn the logging off. *shrug*
NetStumbler for Windows and MiniStumbler for Windows CE downloads are at: NetStumbler.com
I've been told that the software that actually did the sniffing wasn't NetStumbler, but rather it was Kismet. I don't know the original source of who knows this firsthand though, so I can't verify this. However if this is true it's interesting, because it would mean A) Google was likely using a non-Windows system to do the wireless packet sniffing, B) the author of NetStumbler was using another sniffing utility to do the work rather than his own tool, which would be an interesting irony.
Agreed. Layer your services on top of Android and be done with it. Why develop an OS, when a free one is there waiting for you to add to it.
Yeah, that way you can fragment development based not only on what the hardware manufacturer does to the version of Android shipped with the phone, but also fragment as time goes on with various versions of Android.:-/
The issue isn't that they didn't go with Android -- the issue is that there's no compatibility between their old OS and their new OS. Historically that kind of departure doesn't usually work out well.
An example of where this kind of transition works is the migration Apple went through between OS 9 and OS X. OS X shipped with an emulator, "OS Classic", to allow people to run OS 9 applications -- and sometime they later dropped support for this. They also shipped 'Rosetta' to simultaneously support PowerPC and Intel architecture -- and now they're dropping support for that, too. But during the transitions they supported applications, at least for a couple of years. With no similar "transition support", RIM is taking a big risk, and there's a good chance they're going to get burnt, because in terms of application support they're starting from scratch again.
Hm, the rest of the post got a bit long. I'll summarize. Do note that filtering remotely can be on any appliance, doesn't need to be the client machine. Inefficient filter box in the office, client accesses the same IMAP from wherever. Not pretty, but possibly functional. Could turn out to be necessary, as in all other options are not feasible for non-technical reasons. Not advocating it, just noting this sort of thing happens.
It would be very unusual to have another box outside of the mail server and mail client doing mail filtering. In order to not have to do this over IMAP, which would require everybody's login credentials, the external box would need to do direct file manipulation on the server, which would require root access. This would be technically problematic because new mail is delivered simultaneously while the external box would be modifying email accounts. The alternative is for the box to have all of the account details and to log into each account via IMAP and then do the filtering, which is both inefficient and a security issue.
So no matter how I look at it, the "man-in-the-middle" box for filtering doesn't seem like a compelling prospect.
You could think of alternative ways to deploy such things, see if anti-spam services have adaptable models.
As to redmond, they don't understand or wilfully distort email, probably both. A better email client would help here; most existing ones are focused on this or that wrong thing. I see top-posting as integral part of the malady --workflow failure-- and thus a comprehensive solution must address it too, somehow. There's a reason both the FIDO and the internet communities (at least) came up with strikingly formats, more or less independently.
It's typical that the administrator doesn't have a choice of what mail client users use.
The training part, well, there's some interesting developments and I plan on submitting the big players a proposal or two. There are strong incentive arguments itching to be made. More of a bizdev thing than a techie thing, though. Just like the workflow thing isn't really a techie thing either, but does need someone well-versed in the roots of email and online collaboration.
I suspect the lack of general consensus is going to make the big players reluctant to try to push for it. We'll see.
The rest is probably better moved to email. You don't happen to be signed up for Eesley's venture-lab?
No, and this is the first I've heard of Eesley's venture-lab. [And at the moment they seem to be offline for maintenance.] I'm sorry I can't offer you an email address, but I'm purposely keeping my Slashdot identity seperate from others. If I find an email address that is semi-anonymous, I'll send you that.
You're not wrong in your critiques, but nonetheless my reaction is mostly to shrug. The point isn't to look for ways in which the ideas won't work, or ways in which they're inelegant or crufty or whatnot. The point is to take existing things and adapt them so that they do work. In both the technical and the "the user has learned how to do this" sensed.
I'm with you in spirit on this -- I just don't know how to get there.
As a counter-example, I taught my dad to bring up full headers, trace through the Received: lines, and decide whether something was likely a phish or possibly genuine, in about five minutes over the phone. It's not difficult; explain what they're there for and the major clues ("so we've established those emails purporting to be from your bank came in via $country_a_continent_away? what do you think about that then?") to look for, then check they've picked up the gist. Just be very careful with the terminology, use minimal jargon and introduce and explain every term. Standard teaching stuff really.
Yep -- and I've done that, too -- several times. Ask your dad a month later to look at the headers himself. Even if it's as simple as pressing one key (the 'V' key in the case of KMail) -- he probably won't remember how to do it, and he probably will forget most of how to interpret the headers, too. That's what happens with everybody that I explain this to. This happens because needing to read email headers comes up seldomly enough (from their point of view) that they end up not doing it often enough for it to be a practiced skill.
And yes, fetching stuff from a remote, filtering locally, sending it back, then accessing it remotely again isn't the most efficient way to do it. It does work in the absence of everything else--oftentimes SIEVE isn't available and neither is local or shell access-- and can, for example, be scripted and run overnight. If that means your representative is now left with a folder with only response-worthy constituent emails, then the result is still a net win and the one day delay entirely acceptable.
Whether the delay is acceptable or not is entirely dependent on the volume of email and the upload/download speed of the connection avialable. On the volume of email I personally get, which isn't a lot right now (maybe 200 messages/day), with the upload rate I get on cable of of 30 kB/sec, performance was abysmal, and definitely not acceptable. [There was a time as an email admin that I was getting about 10,000 messages/day. Local filtering via POP using KMail I was able to get and automatically filter all of that email in about one minute.]
From that experience, I view local fiilering over IMAP as the wrong solution. Email needs to work on wifi, on LAN, in a hotel, etc -- i.e. in many enviornments that cannot be controlled.
Of course, there are better ways, which is why I sketched a number of approaches. Personally I think it must include user training, including efficient email writing, etiquette (no bloody top-posting), header structure, advanced filtering tool use, understanding how to forward with full headers, learning to use a better email client, and so on. To me this makes sense for such heavy users. Not only do they obviously need good tools, they need to know how to use them well, too. So teach them. There is an awful lot that can be done there.
Re: top posting -- I recommend letting that fight go. These days top posting is so common that it's not something to bother complaining about. [Personally, I'd much rather fix those bloody advertisement tags at the bottom of email like "Sent from my ".] MS Outlook seems to promote top posting, as do most of the mobile devices. Don't get me wrong, I hate top-posting too, but I've deemed the fight not to be worth it.
I like your enthusiasm for educating people and helping them -- all of that is good. Hopefully you'll be able to find a way to accomplish what you want -- heck I'd even be happy to try to help if you'd like. If you can think of what you'd like to see done to help this, let me know and I'll be willing to join the effort.
IMHO it only works if it's "dead simple" to use -- and my experience is that very few non-techies learn to do any of this. [Even many techies don't!]
Shouldn't be too hard to figure out who the interest groups are, then dump them in a separate folder.
...
Anyway, procmail is just one way. SIEVE support on your IMAP server would be another. Plenty mail clients have custom filtering, there exist toolsets to run commands on an imap, again possibly in conjunction with procmail, and maybe there already exists a GUI to ease such use for the lesser educatable beings among us, or else it is easily whipped up.
If rules won't do, then train a bayes filter (like spamassassin) on an interest group mass-mailings set and have it dump them in a separate (non-spam) folder. You can use the same technology for multiple targets, not just spam/non-spam.
...
Work this out and offer your services to your representatives, for a modest fee. Should be a nice weekend-earner. Royalties to the usual address please.
Having done this for a long time, here are a couple of problems I see with the idea:
- Most people don't know how to read email headers, which makes making filter rules for them more difficult.
[Filtering on Subject: or From: really doesn't work.]
- Email headers are stripped in a forward or a reply, which makes sending the email to a tech to have them make rules more difficult.
- The command to view email headers is generally different on EVERY email cilent, and really stinks on MS Outlook.
- A politician with a shell login? Um... yeah.
- A politician with a shell login that can correctly edit procmail rules? You're dreaming.
- A politician that can edit SIEVE rules via ManageSieve... better chance (and far nicer than procmail), but still doubtful. And ManageSieve is new enough that a lot of email clients don't support it yet.:-/
There are also some technical issues getting SIEVE filtering working server-side on some systems. For instance Exim has its own way of doing this that doesn't seem to work well with Dovecot's ManageSieve service, so you end up having to have Dovecot become the end delivery agent to get SIEVE filtering working correctly.
Occasionally I'm able to teach a non-techie how to make their own local filter rules, but so far that's basically only been successful for spam classification.:-/ Very few non-techies (or techies, for that matter) have their email moved into folders automatically. Plus -- oh by the way -- doing this "locally" via IMAP stinks because it means the mail client has to download the email, classify it, then upload the email to the server again. That's dumb. Upload speeds often suck, thus so does email performance.
Look more into this -- and try it -- you'll see what I mean.
can't the University of Pittsburgh and the Pittsburg police stop doing that and ignore the bomb threats, knowing that their leg is being pulled? [...] "The boy who cried wolf" should also come into play
There are two morals to the story of "The boy who cried wolf":
Don't consistently lie or you'll get eaten (the moral for children)
Sometimes, children's lies end up being the truth, so pay attention every time or they'll get eaten (the moral for adults)
If you want to discourage lying, punish the liars when they're caught, but don't ignore what seems like a lie because it might be the truth.
Point taken. [Several others have essentially said the same thing, but I believe the above is the most succinct/eloquent statement of it.]
Slashdot Mirror
Since it is open source, we can always fork it. And normally the fear of forks will stop the corporation from acting too badly - doing evil to open source software does not pay.
In the case of Canonical, we have an additional assurance: it is a private company, which does not have a fiduciary duty to maximize profits. It was founded by Mark Shuttleworth, who is a nice guy and was a Debian Developer.
Yes, I met him in person during DebConf10. Very friendly guy; I saw his talk on the Unity interface. I think the Debian developers have sort of an interesting like(--)standoffish relationship with Mark Shuttleworth. My impression was that he's well respected in the Debian community at the same time that many wish his efforts were in Debian rather than Ubuntu. [Nobody actually voiced this though.]
In the case of Ubuntu, the "evil" was selecting Unity as default. However, Xfce, LXDE, KDE and others are still available, and they are working on GNOBuntu (with the full Gnome, including the Gnome Shell). Despite the hate you see on Slashdot, Ubuntu is still the number 1 distribution - see http://en.wikipedia.org/wiki/Ubuntu_(operating_system)#Installed_base.
And, personally, I use Unity and like it just fine.
Well, Canonical also pulled the funding of Kubuntu back in February.
http://news.slashdot.org/story/12/02/07/0143224/canonical-pulls-kubuntu-personnel-funding
On http://distrowatch.com/ Ubuntu is #2 behind Linux Mint. Mint has two versions, one based on Ubuntu and one based on Debian -- and I believe it's the one based on Ubuntu that is most popular, which comes with either MATE, Cinnamon (Gnome2-like interface), KDE, or Xfde. Since Mint 13 is most popular, it's clear that many others don't like the Unity interface. :-P [So in effect I agree with you, just in a slightly different way.]
X is pretty huge and I'll bet it didn't just do the drivers you need but all of X - then there's KDE and a pile of apps there, I'll bet openoffice was in there too, so it comes down to Gentoo not being fine grained enough to cope with that situation with the options you told it to do (or not clearly telling you the consequences of your choices).
I followed /etc/X11 and manually set the video driver to either vesa or vmware, but after three days of compiling I was impatient to get the testing I needed to do over with. :-P
http://www.gentoo.org/doc/en/xorg-config.xml
and I decided to use 'emerge -pv xorg-drivers'. I was not able to get X to start afterwards. Not a big deal; I ended up using ssh and X forward to do the testing I needed to do. If I was really interested in running Gentoo I probably would have created an xorg.conf file in
I've been there, done that with a little slow fanless VIA system that could actually benefit from specific compiler flags so Gentoo actually made some difference, and it was more than one day to get what I wanted even though I didn't go overboard and went for fluxbox instead of gnome or kde. Package management is there in all the other distros to avoid such annoyances and in most cases the stuff is compiled to take full advantage of whatever CPU you have anyway.
It should have said on the tin that Gentoo is all about insanely long compiles, but it's there in the docs if you look hard enough (eg. instructions on cross compilation for older hardware imply that it's going to take a very long time, so it gives you the option to do stuff on another faster machine instead). I played with it for a bit but that little slow box has Fedora on it now and a only a few things I've put on from source are actually optimised for that CPU. When you think about it the only times you really care about what the CPU is doing is in a very small number of appications that run it flat out and not the kernel, not X and not the window manager. Just compile gimp, vlc, firefox or whatever to use the hardware as well as it can run and you'd probably get all of the benefits of Gentoo on odd hardware, and if it's not odd hardware they'll just be a binary package that will do it just as well for you anyway.
The three-day compile was in a VirtualBox VM using both cores of a 2.5 GHz Core2Duo with 1024 MB of RAM dedicated to the VM. There's an irony in running Gentoo in that the reason given to run it is "speed", but to get that speed requires lots of compiling, which is slow.
There must be a way of installing pre-build binaries with Gentoo, as I've heard rumor of it, but I didn't find it myself. Probably a command-line switch to 'emerge'. If I end up running Gentoo again I'll try to figure that out. ;-)
"Anytime the USE flags get updated Gentoo wants you to 'emerge @world' to recompile the whole system again..."
No, you'll just need to recompile the packages affected by the USE flag changes:
emerge --newuse --deep @world
Ah. Okay -- on that I stand corrected, then -- and I appologize for propagating misinformation.
Thanks.
If you're building Chromium, or OO.Org from source on hardware built five years ago, system updates in Gentoo are a bit slow. But, Gentoo is fantastic for doing dev work. More often than not, I'll find that "apt-get build-deps" (or whatever it is that installs the *-dev packages that are required to build a package in the tree from source) just doesn't work. In gentoo: "emerge --only-deps $PACKAGE" *always* works. :)
Debian these days uses an automated build system; part of the reason is to catch issues where "apt-get build-dep (package)" doesn't pull in all of the required "-dev" development packages required to build the source package. This was done because otherwise there were too many "FTBFS" (Fails To Build From Source) problems like you're describing. IIRC I think this might have been something Ubuntu did first and then Debian picked up on sometime later.
The "figuring out which -dev packages to install" is still an issue for normal non-Debian source compiles, though. BTW if you end up using a Debian box for development again sometime, check out the 'checkinstall' package, as what it does is interesting. In the "normal" manual software installation steps of 1) ./configure 2) make 3) make install, you just change step 3 to "checkinstall make install" and what checkinstall does is make a fake Debian package containing the list of files that were installed, so that dpkg won't trample them. :-)
. IMHO the best feature Debian has is the ability to upgrade-in-place -- so you never have to do a reinstall to keep it up-to-date unless you want to.
Indeed, I have installations of Debian that are 13 years old. They've been through multiple hardware revisions, and are now virtualized, but apt-get dist-upgrade has done the trick all this time.
However, technical achievements aside, it's Debian's policy that's the real star.
For the most part I agree concerning Policy, but there are lots of niche areas that Policy doesn't currently cover. To give you an idea of what I mean, there's a whole lot of discussion going on right now on [debian-devel] concerning:
- packages with same binary names in different directories [/usr/sbin vs /usr/bin] /bin with /usr/bin, possibly merging /sbin with /usr/sbin
- possibly merging
- policy issues concerning different init systems [file-rc, systemd, upstart, openrc]
- issues with who gets to choose what the default desktop environment will be
So Debian's Policy covers a lot, but there's still enough wiggle room in it that vigorous debates on lots of such topics are commonplace, and these end up changing Policy some. As a "normal user" we end up seeing the results as sweeping changes that comes down, like the switch from devfs to udev.
So rather than put my faith in Policy, generally I put my faith in "the Debian people". Because the excellent results are due to the efforts of the developers themselves, rather than due solely to the Policy that they work under. ;-)
The wheezy installation I ran two weeks ago told me that I needed two binary non-free packages and asked if I wanted to load them from another device.
I didn't try it though because I installed via a wired network.
It was probably related to Wireless hardware; the base Debian install these days ships only "free software", so by default you only get the package "firmware-linux-free" that contains firmware for 20 or so devices. Most of the firmware required to run Wireless cards are binary-only blobs that are considered "nonfree" in that you cannot see the source code for them, so that's why they're in the "non-free" section and don't come with the base install. [This is where Debian developers are purists, but I think it's for good reason.]
This can be frustrating if you're trying to do a network install over a Wireless card, which is why the option exists to load them from another device like a USB stick. Presumably you'd use another computer and download the necessary firmware and put it on a USB stick after finding it on http://packages.debian.org/ in the "Kernels" area.
I see no problem with some corporation being associated with the project. If there are reasonable rules, and if the project has a reasonably open governance, corporate help is welcome.
To an extent it's fine, but the corporation usually ends up steering the project to some extent. For instance is Ubuntu more community-driven or Cononical driven? Is Fedora community-driven, or is it a platform for developing RHEL? What about Oracle? For instance when I think of Ubuntu, I ask the question "Who made the choice of the 3D Unity interface? Was it the community or was it Cononical?"
Corporations often have different needs than a home user does. Debian, for instance, contains a bunch of niche packages like those used by Amateur Radio operators. These are things you're not likely to see in an "Enterprise" distribution. So what you get as a user does differ depending on who is directing the distribution development. This doesn't make choosing an "Enterprise" distribution wrong of course -- it might be what you need.
It doesn't sound like you really know how to use gentoo based on what you're saying. I've built KDE and a system from scratch and it doesn't take one day let alone three.
No, it really took three full days for the base system + base KDE4 within a VM. I used the instralll instructions from Gentoo's website.
http://www.gentoo.org/proj/en/desktop/kde/kde4-guide.xml
Also, don't set USE flags system wid unless you know you want to, that's what /etc/portage/package.use is for.
See the link above; the instructions has one change the USE flags, and then has one run 'emerge -uDNav world'.
You're correct that the USE flag was --newuse and not --newuser. Your comment otherwise was quite rude. Surely using elitism isn't going to help the Gentoo project.
I suppose that it's long past time that I installed Debian. I've fought through Gentoo army of config files, gone through RPM hell with Red Hat and Mandrake, hacked at the jungle thicket of Fedora and swam in the cool waters of Arch. I've tried two Debian-based distributions, but never install Debian. Does it offer any real advantage over Arch?
Just recently I tried the top 25 free software distributions [as measured by distrowatch.com], one of which was Arch. I have to say Arch was one of the distros I found fun to play with -- the only thing I think is missing is a simple graphical installer. The first set of instructions I found on the Arch website weren't complete concerning the Grub2 install, leading to install and bootup failures, but the "Beginner's Guide" has complete instrcutions for the install. Package installation under arch is super fast. I couldn't get audio working in the VM I was installing it in, but other than that I really liked it.
And I tried Gentoo as well, and I found it just as hateful as I found it in 2003, if not more so. The "install", or shoud I say the compile, took three solid days to install a base system + a base install of KDE 4.8. The 'emerge' command often ran into dependency hell, forcing the use of several switches like 'emerge --newuser --update --deep (package)'. Anytime the USE flags get updated Gentoo wants you to 'emerge @world' to recompile the whole system again, and of course the instructions for intalling KDE4 has you modify the USE flags. I really do love a lot of the documentation I can get from the Gentoo project, but in terms of running it as a distro I want to keep it as far away from me as I can, because frankly I think it's insane.
Debian has a graphical installer, and you can choose several Desktop Environments right at the very start of the install menu. I think it's the only distro (or one of very few) that shows all of the choices of languages in their own native written language rather than the list being all in English. Debian is also the basis for a long list of other distros -- out of the top 25, 12 are Debian derivatives. IMHO the best feature Debian has is the ability to upgrade-in-place -- so you never have to do a reinstall to keep it up-to-date unless you want to. Debian has a lot of developer support behind the project, most of whom are free software purists -- which is generally a good thing. It's one of the very few distros that are based solely on donations and have no private corporation behind them. If you want to know more about Debian, my first suggestion is to watch an intro video given by Bdale Garbee from DebConf11 which I think was well spoken and informative:
http://penta.debconf.org/dc11_schedule/events/804.en.html
I don't know enough about Arch to give a fair comparison between it and Debian; all I can say for the moment is that I've been running Debian for 13 years, and that in the very limited time I've spent with Arch I've been impressed with it.
The distributions I liked in testing them: Linux Mint Debian, Fedora 17, openSuSE, Debian, Arch, Pear Linux 5 (appearance of Mac OS X), SnowLinux 2 "Ice", and the DVD version of Knoppix 7.03. Distros I did not like: Ubuntu 12.04 (3D, Unity GUI), Mageia 2, PCLinuxOS (only "rpm" lines in /etc/apt/sources.list), Ultimate 3.4 (3D), Gentoo (insane long compiles), Fuduntu (yucky package installer), SolusOS (yucky package installer).
Concerning letters of recommendation: they do not have to come from professors or from a boss. When I went back for my MSEE, I used letters of recommendation from two colleagues and one from a friend. If letters specifically need to come from someone you've worked for then that will be stated in the requirements for entry from the particular graduate school you apply for.
You'll need to get official transcripts from each of the colleges you've attended. Typically these are required to come in envelopes with a signature over the seal. I suggest ordering an extra copy from each school for your own records. [This is mostly "just a good idea", but there are cases where schools have lost their records. The University of New Orleans, for instance, lost my sister's academic records there after the school was flooded during hurricanes Katrina back in 2005.]
The next thing you'll need to do is take the Graduate Record Exam (GRE). Having taken it I'll give you the following advice: concerning the Quantitative section what you most need to know is if you can answer each question you're given in less than 2 minutes. The computerized version of the test also does not allow you to go back and change your answers, because the test is adaptive -- the questions get harder as you answer lower questions correctly. Harder questions are also worth more points, so it's very important to answer the lower questions correctly in order to get to the harder ones. The paper-based GRE exam doesn't have these issues, if these are still being offered. In the Verbal section of the GRE, if possible be creative in your essay writing. At the end of the GRE exam you're asked what schools you want your GRE scores to be transmitted to (after you're told what they are right then and there, except for the essay section), so you should know what schools you're planning to apply to beforehand.
Your transcripts and letters of recommendation are generally given to the school with your application. The GRE scores are transmitted directly to the school.
Good luck and enjoy grad school. ;-)
It's a Scottish lake.
.... "many miles aaaawaaaaaay"
I love that song by The Police.
All I can do is express my confusion. Nokia purchased Qt presumably with the intent of using it on their phones. They put out a couple of very good phones such as the N900 that leveraged Debian and Qt. All of that seemed like they were on the right path. Debian users practically swear by the N900.
And then... they announce plans to switch to a non-existent Windows platform. What? That was a total reversal of course away from what was previously a direction of free and open source software. Somewhere in the company I'm betting the reasoning given has to do with a spreadsheet of expected costs of development between the Qt and Windows platforms, and my personal bets are on those numbers being wrong and thus the wrong decision being made.
What matters to me personally is that Qt support structure survives this intact, because it's a very important framework. Thankfully Qt is GPL software, so the existing code will survive no matter what.
I don't suppose you have a reference source for this?
I found a reference, but it seems to indicate that the length of time the various providers store location information is shorter than I had remembered.
http://www.aclu.org/cell-phone-location-tracking-request-response-cell-phone-company-data-retention-chart
The cellular network has to know where you are to route calls to you. Back when they first came out, someone published an article about using cellular information to locate a person with his cell phone to within 36 feet.
Yes... additionally, last I recall this information is saved for a period of 7 years, which means not only does the phone system know where you are now, but it also knows where you've been. This means that you can be profiled based on the places you go, and thus there's a chance someone can predict where you're going to be at any given time.
93 deg F now, a week ago it hit 97 deg F for three days.
No major power outages in the area.
We have not run A/C at all yet. (We have one small window A/C unit if we get desperate.)
Our basic strategy is to open the windows at night an run fans, and turn the fans off and close the windows (and storm windows) at 7am. Our house seems to be insulated well enough that it stays cooler indoors than outdoors most of the day. Open windows and use fans again at 8pm. If it gets too hot, opt for showering in cool water -- this requires power because we have well water rather than municipal water.
Come on folks, of course I know who Linus is. Sheesh. Do I gotta put a smiley every time? (Apparently some people got it).
I realized it afterwards when I noticed the post was modded as Funny. :-P [As such -- sorry for the unnecessary reply.] ... er... "uninformed".
Thing is, some people really are just that
I don't know who this "Linus" guy think he is. Just because his name looks kinda similar to "Linux" doesn't mean he has the right to be jerk. The community should flame him off the forums because he apparently doesn't understand the open source ethos.
I notice that you didn't say he's wrong. And he openly admits he's strongly opinionated.
If he was a real programmer he'd just dig into the code and fix these problems.
He is, and he has -- simply as an example, he sent in patches to Gnome back when he complained about the lack of mouse configuration. But there's only a certain amount of this that is reasonable. Sending in a patch for a tweak can be expected -- sending in a patch to fix major design decisions is definitely not.
You can turn Nepomuk OFF. Unfortunately, Akonadi is another story. [more below]
We're a Linux shop with around 400 desktops and have been running KDE for a decade. KDE3 was rock solid. KDE4, not so much. The KDE4 direction of "let's index everything" with nepomuk and akonadi doesn't work so well when home directories are NFS mounted. In fact, it killed our fileserver. Further, why on earth would I want 400 instances of mysql_community_server running and creating a 128MB DB for each user in their home directory just to index their PIM?
I don't blame you one big for moving to XFCE; AFAIC it's the next-best alternative to KDE4. You're probably set with XFCE for the near future, but I'll point out the following in case in the future you retest KDE4.
Nepomuk can be turned off (on a per-user basis) by going to K->System Settings and then Workspace Appearance -> Desktop Search and turning off both the "Strigi Desktop File Indexer" and also "Nepomuk Semantic Desktop". Performance for Strigi indexing is still awful even on a local disk, let alone NFS, so I regularly turn these both completely off. Nepomuk still needs to be turned off IMHO, otherwise the Virtuoso database backing it slowly grows as you use the system. It isn't easy to find exactly what this does and what use you can make of it, but the following is a good resource that explains it:
https://kdenepomukmanual.wordpress.com/2012/02/06/detailed-kde-nepomuk-manual/
Unfortunately Akonadi cannot be completely turned off AFAIK -- and what's sad is that (as you correctly pointed out) it does not store information, but rather only indexes PIM information. By default Akonadi has a dependency on MySQL, and EACH user that logs in requires starting a dedicated instance of MySQL server. That's a huge WTF right there. However -- you can reconfigure Akonadi (on a per-user basis) to use SQLite instead of MySQL in .config/akonaki/akonadiserverrc. But another WTF is that this has to be set up on a per-user basis. Apparently at one time there was a server-wide setting available, but if it exists today in KDE 4.8 I'm unable to find it or even a reference to it. :-/
With Nepomuk turned completely off and Akonadi set up to use SQLite, KDE4 is performs much better. Unfortunately there are certain things that Akonadi apparently cannot store in SQLite, so supposedly there can be issues with using it, but in practice I haven't run into any of them.
VLC rocks
VLC works for about 90% of the DVDs and videos I'll download off the Internet. It works well enough for me, well enough that I haven't needed to use WMP to play a video in a long long time.
IMHO, not only does VLC work just as well as Windows Media Player for Vista, but I find it's actually preferrable to WMP.... so much so that I uninstalled WMP entirely. And like you, I've yet to find a DVD that VLC won't play.
The only thing with VLC is I have to remember to reconfigure it so that the mouse scroll button scrolls the time index of the media rather than the volume.
Adding to this, Netstumbler can't even capture data as its hopping channels. The only way to accomplish this if the author wrote another program that used another wireless card to sniff on the selected channel, which seems highly unlikely.
If word got out what software Google was doing to accomplish this, wouldn't you think it would inspire someone to find ways to break it when a Google car is in your neighborhood? Presuming of course, they simply turned off the pcap capturing and continue to use it.
Interesting -- NetStumbler sounds like a very different tool than Kismet is. Concerning the packet sniffing Google did, my understanding is that the main issue was sniffing and storing of unencrypted packets, so yes, that would generally be easy to fix by turning encryption on. My understanding is that Google was likely mostly interested in sniffing and storing the SSIDs of access points along with GPS data on where they were located, and context like whether the AP was encrypted. In other words, they were essentially "war driving" while collecting map data. I don't think they had any ill intent, and likely just forgot to turn the logging off. *shrug*
NetStumbler for Windows and MiniStumbler for Windows CE downloads are at:
NetStumbler.com
I've been told that the software that actually did the sniffing wasn't NetStumbler, but rather it was Kismet. I don't know the original source of who knows this firsthand though, so I can't verify this. However if this is true it's interesting, because it would mean A) Google was likely using a non-Windows system to do the wireless packet sniffing, B) the author of NetStumbler was using another sniffing utility to do the work rather than his own tool, which would be an interesting irony.
Agreed. Layer your services on top of Android and be done with it. Why develop an OS, when a free one is there waiting for you to add to it.
Yeah, that way you can fragment development based not only on what the hardware manufacturer does to the version of Android shipped with the phone, but also fragment as time goes on with various versions of Android. :-/
The issue isn't that they didn't go with Android -- the issue is that there's no compatibility between their old OS and their new OS. Historically that kind of departure doesn't usually work out well.
An example of where this kind of transition works is the migration Apple went through between OS 9 and OS X. OS X shipped with an emulator, "OS Classic", to allow people to run OS 9 applications -- and sometime they later dropped support for this. They also shipped 'Rosetta' to simultaneously support PowerPC and Intel architecture -- and now they're dropping support for that, too. But during the transitions they supported applications, at least for a couple of years. With no similar "transition support", RIM is taking a big risk, and there's a good chance they're going to get burnt, because in terms of application support they're starting from scratch again.
...
Hm, the rest of the post got a bit long. I'll summarize. Do note that filtering remotely can be on any appliance, doesn't need to be the client machine. Inefficient filter box in the office, client accesses the same IMAP from wherever. Not pretty, but possibly functional. Could turn out to be necessary, as in all other options are not feasible for non-technical reasons. Not advocating it, just noting this sort of thing happens.
It would be very unusual to have another box outside of the mail server and mail client doing mail filtering. In order to not have to do this over IMAP, which would require everybody's login credentials, the external box would need to do direct file manipulation on the server, which would require root access. This would be technically problematic because new mail is delivered simultaneously while the external box would be modifying email accounts. The alternative is for the box to have all of the account details and to log into each account via IMAP and then do the filtering, which is both inefficient and a security issue.
So no matter how I look at it, the "man-in-the-middle" box for filtering doesn't seem like a compelling prospect.
You could think of alternative ways to deploy such things, see if anti-spam services have adaptable models.
As to redmond, they don't understand or wilfully distort email, probably both. A better email client would help here; most existing ones are focused on this or that wrong thing. I see top-posting as integral part of the malady --workflow failure-- and thus a comprehensive solution must address it too, somehow. There's a reason both the FIDO and the internet communities (at least) came up with strikingly formats, more or less independently.
It's typical that the administrator doesn't have a choice of what mail client users use.
The training part, well, there's some interesting developments and I plan on submitting the big players a proposal or two. There are strong incentive arguments itching to be made. More of a bizdev thing than a techie thing, though. Just like the workflow thing isn't really a techie thing either, but does need someone well-versed in the roots of email and online collaboration.
I suspect the lack of general consensus is going to make the big players reluctant to try to push for it. We'll see.
The rest is probably better moved to email. You don't happen to be signed up for Eesley's venture-lab?
No, and this is the first I've heard of Eesley's venture-lab. [And at the moment they seem to be offline for maintenance.] I'm sorry I can't offer you an email address, but I'm purposely keeping my Slashdot identity seperate from others. If I find an email address that is semi-anonymous, I'll send you that.
You're not wrong in your critiques, but nonetheless my reaction is mostly to shrug. The point isn't to look for ways in which the ideas won't work, or ways in which they're inelegant or crufty or whatnot. The point is to take existing things and adapt them so that they do work. In both the technical and the "the user has learned how to do this" sensed.
I'm with you in spirit on this -- I just don't know how to get there.
As a counter-example, I taught my dad to bring up full headers, trace through the Received: lines, and decide whether something was likely a phish or possibly genuine, in about five minutes over the phone. It's not difficult; explain what they're there for and the major clues ("so we've established those emails purporting to be from your bank came in via $country_a_continent_away? what do you think about that then?") to look for, then check they've picked up the gist. Just be very careful with the terminology, use minimal jargon and introduce and explain every term. Standard teaching stuff really.
Yep -- and I've done that, too -- several times. Ask your dad a month later to look at the headers himself. Even if it's as simple as pressing one key (the 'V' key in the case of KMail) -- he probably won't remember how to do it, and he probably will forget most of how to interpret the headers, too. That's what happens with everybody that I explain this to. This happens because needing to read email headers comes up seldomly enough (from their point of view) that they end up not doing it often enough for it to be a practiced skill.
And yes, fetching stuff from a remote, filtering locally, sending it back, then accessing it remotely again isn't the most efficient way to do it. It does work in the absence of everything else--oftentimes SIEVE isn't available and neither is local or shell access-- and can, for example, be scripted and run overnight. If that means your representative is now left with a folder with only response-worthy constituent emails, then the result is still a net win and the one day delay entirely acceptable.
Whether the delay is acceptable or not is entirely dependent on the volume of email and the upload/download speed of the connection avialable. On the volume of email I personally get, which isn't a lot right now (maybe 200 messages/day), with the upload rate I get on cable of of 30 kB/sec, performance was abysmal, and definitely not acceptable. [There was a time as an email admin that I was getting about 10,000 messages/day. Local filtering via POP using KMail I was able to get and automatically filter all of that email in about one minute.]
From that experience, I view local fiilering over IMAP as the wrong solution. Email needs to work on wifi, on LAN, in a hotel, etc -- i.e. in many enviornments that cannot be controlled.
Of course, there are better ways, which is why I sketched a number of approaches. Personally I think it must include user training, including efficient email writing, etiquette (no bloody top-posting), header structure, advanced filtering tool use, understanding how to forward with full headers, learning to use a better email client, and so on. To me this makes sense for such heavy users. Not only do they obviously need good tools, they need to know how to use them well, too. So teach them. There is an awful lot that can be done there.
Re: top posting -- I recommend letting that fight go. These days top posting is so common that it's not something to bother complaining about. [Personally, I'd much rather fix those bloody advertisement tags at the bottom of email like "Sent from my ".] MS Outlook seems to promote top posting, as do most of the mobile devices. Don't get me wrong, I hate top-posting too, but I've deemed the fight not to be worth it.
I like your enthusiasm for educating people and helping them -- all of that is good. Hopefully you'll be able to find a way to accomplish what you want -- heck I'd even be happy to try to help if you'd like. If you can think of what you'd like to see done to help this, let me know and I'll be willing to join the effort.
IMHO it only works if it's "dead simple" to use -- and my experience is that very few non-techies learn to do any of this. [Even many techies don't!]
Shouldn't be too hard to figure out who the interest groups are, then dump them in a separate folder.
...
Anyway, procmail is just one way. SIEVE support on your IMAP server would be another. Plenty mail clients have custom filtering, there exist toolsets to run commands on an imap, again possibly in conjunction with procmail, and maybe there already exists a GUI to ease such use for the lesser educatable beings among us, or else it is easily whipped up.
If rules won't do, then train a bayes filter (like spamassassin) on an interest group mass-mailings set and have it dump them in a separate (non-spam) folder. You can use the same technology for multiple targets, not just spam/non-spam.
...
Work this out and offer your services to your representatives, for a modest fee. Should be a nice weekend-earner. Royalties to the usual address please.
Having done this for a long time, here are a couple of problems I see with the idea: :-/
- Most people don't know how to read email headers, which makes making filter rules for them more difficult.
[Filtering on Subject: or From: really doesn't work.]
- Email headers are stripped in a forward or a reply, which makes sending the email to a tech to have them make rules more difficult.
- The command to view email headers is generally different on EVERY email cilent, and really stinks on MS Outlook.
- A politician with a shell login? Um... yeah.
- A politician with a shell login that can correctly edit procmail rules? You're dreaming.
- A politician that can edit SIEVE rules via ManageSieve... better chance (and far nicer than procmail), but still doubtful. And ManageSieve is new enough that a lot of email clients don't support it yet.
There are also some technical issues getting SIEVE filtering working server-side on some systems. For instance Exim has its own way of doing this that doesn't seem to work well with Dovecot's ManageSieve service, so you end up having to have Dovecot become the end delivery agent to get SIEVE filtering working correctly.
Occasionally I'm able to teach a non-techie how to make their own local filter rules, but so far that's basically only been successful for spam classification. :-/ Very few non-techies (or techies, for that matter) have their email moved into folders automatically. Plus -- oh by the way -- doing this "locally" via IMAP stinks because it means the mail client has to download the email, classify it, then upload the email to the server again. That's dumb. Upload speeds often suck, thus so does email performance.
Look more into this -- and try it -- you'll see what I mean.
can't the University of Pittsburgh and the Pittsburg police stop doing that and ignore the bomb threats, knowing that their leg is being pulled? [...] "The boy who cried wolf" should also come into play
There are two morals to the story of "The boy who cried wolf":
Don't consistently lie or you'll get eaten (the moral for children)
Sometimes, children's lies end up being the truth, so pay attention every time or they'll get eaten (the moral for adults)
If you want to discourage lying, punish the liars when they're caught, but don't ignore what seems like a lie because it might be the truth.
Point taken. [Several others have essentially said the same thing, but I believe the above is the most succinct/eloquent statement of it.]