Slashdot Mirror

Not really.

All of it is simply in the linux-firmware-nonfree package now.

Typing this on a Lenny Mac mini G4 with a backported kernel package and with the radeon happily loading its non-free firmware out of the similarly backported non-free firmware package. Ditto for my G4 Powerbook (TiBook), ditto for my spare laptop which is a HP NC4000 in need for a non-free wireless card driver, firmware (non-free) for the onboard radeon and so on.

The only missing bit last time I checked was however something which is quite important - the nvidia packages. By the way the NV drviver is absolutely not an answer here and not for performance reasons. NV does not have working power management. On half of the hardware currently shipping out there it is a sure way to fry your card. It may not be fried immediately. It may take months or even a year or two for it to die, but die it will and it will die prematurely. That has been actually been the case for 5+ years now.

So unless Debian wants to take the responsibility for something that can actually damage people PCs they will have to swallow the bitter pill and find a way to ship nvidia drivers (and have them properly configured powerwise which by the way no Linux distro does at present). It is not that difficult: http://foswiki.sigsegv.cx/bin/view/Net/LinuxNvidia

Depends which ones. I have tried making a media center out of nearly anything short of a dead badger. Based on my experience:

Most VIA EPIAs have sound quality on par with discrete audio solutions. It is something you can hook to a proper amp and not be disgusted by what comes out from the other end. Most via based mini-ITXes can proudly play flac encoded audio with proper Hi Fi quality. So are some of the older Crystal Audio chipsets found on really old high end motherboards.

Compared to that most audio on Intel chipset motherboards I have had to deal with is utter tripe (with the notable exemption of Asus). The most common problems are:

1. Interference from the network hardware. As the network works it "ticks" over the audio channel. Makes a PC totally unusable for music. This is more common on older kit, though I still see it here and there even today.
2. IRQ interference problems on new hardware. I thought that shared IRQ problems are something of the distant (circa 1998) past. Recently Fujitsu-Siemens and Intel proved me wrong. The Intel HD on the Scaleo-E needs special IRQ tweaking on Linux in order not to skip: http://foswiki.sigsegv.cx/bin/view/Net/DebianScaleoE
3. Distortion. Most onboard Intel HD audio has notable distortion in the high freq range. Examples - HP 6xxx series laptops, Lenovo S10e.

You get whatever you pay for. Viva le monopoly - result is crap video, crap audio, crap disk IO and the consumer is blaming it all on guess what - the too slow CPU so they are aiming to get a bigger one for Xmas which is in favour of guess who...

Didn't they make some hideously expensive RAM that was supposed to perform twice as well as normal RAM, but never lived up to the hype?

It actually does. Or at least used to all the way until Core came out. I have a dual P3 733MHz, Intel 840 chipset with a dual channel RAMBUS in the loft (old HP Kayak).

http://foswiki.sigsegv.cx/bin/view/Net/DebianXU800

It performs better than a lot of P4s or anything prior to Core systems. The problem with Rambus was that it was so hideously expensive that noone could afford a sane amount of memory so any advantage achieved through RAM speedup was lost on VM swapping madly. If you manage to collect enough RDRAM from skip diving a RAMBUS system is actually worth having. I have managed to obtain 768M through skip diving which makes mine just reasonable enough for a workstation.

It is nowdays fairly irrelevant because Intel and AMD have optimised their CPUs for DDR RAM. They are loaded to the gills with cache and this nullifies the RDRAM lower access latency advantage.

Propping a filter is the wrong idea. IMO the best use is to feed them as a spambait for autogenerated dynamic blacklists. Unfortunately this means running your mail server so gmail is out of the question.

Essentially, the idea is that you keep a list of addresses that are no longer in use (or known to be compromised) and any host sending mail to them is set to a "DENY ALL" status for 24-48 hours. If you overlay this on top of greylisting, the efficiency of is as good as Spamhus XBL-SBL. In total these block 99.5% of incoming SPAM. Unfortunately XBL-SBL and dynamic blacklisting give only minimal further improvement when used together. The reason is that blacklisting has nearly 99% correlation with Spamhaus as far as what it would deny. This is not surprising, considering that Spamhaus uses spambaiting as the primary means to populate its database.

Absolutely.

And, for all practical purposes the fear of harvested mail addresses is silly, irrational and stupid. There is a very good method of dealing with harvesters. You combine greylisting with spambait driven blacklists and you get 99% of them right away.

Note - it is essential to use both grey and black in order for it to work. Using greylists allows to defer all mail until the spammer has fired its entire volley. If one of the addresses in the volley is a spambait you blacklist the source IP with a dynamic entry for let's say 24 hours and simulate that you are still greylisting. As a result the spammer does not know which addresses are bait and cannot prune its database. When (and if) the spammer comes around for a queue rerun you tell him to buzz off.

My email address is all over the internet from posts to mailing lists and such and it has been harvested thousands of times. If I do not use any server side antispam I get around 300+ SPAMs a day. After using grey+black+sorbs I get on the average under 2-3 spams a day. All I need to do to maintain the scheme, is to add some spambait from time to time here and there as well as pick up potential spambait from mail bounces. Most harvesters are badly written and will pick up Message-IDs as valid email addresses. These will bounce so picking them out of the error log and adding to the spamtrap triggers is a good way to populate it right away.

Works a treat : http://www.sigsegv.cx/exim-greylist-4.html

In addition to that the Citrix client can run it on Linux based thin clients like the one I am typing this in http://www.sigsegv.cx/hp-thin-client.html (I am a big fan of "eat your own dogfood"). Personally, I have replaced the OS, but in an enterprise environment you are obviously better off keeping the original and using bundled Altiris for management.

Based on the stuff shipped by HP, my overall impression is that while Thin Client Winhoze starts lower than Linux (at 64MB RAM/64MB Flash), it becomes viable at 256/128+ which starts to defeat the purpose. Linux in such an environment is really "thin" because there is no choice but to push via Citrix to it and the temptation to run things locally goes away. As a result you are perfectly OK with 128/128. As far as CPUs are concerned both the HP old ones (Transmeta) and new ones (Via C3) are complete overkill for the job. I am tracking the CPU usage on mine (Transmeta 800) and it never goes above 15%.

Advantages:

• Ease of setup. Once you have an SSL CA setup the OpenVPN part is a piece of cake
• Possibility to use multiple links, load balance, failover, hang yourself by any means necessary. See Caveats though...
• Possibility to use QoS and run VOIP on top with no worries. While IPSEC security is considerably better studied than OpenVPN (this does not mean it is better, it is just a devil we know), IPSEC has a major failing. In its most common VPN use which is tunnel mode it is utter piece of horrid shite as far as QoS is concerned. Shameless plug: you can lift off QoS setup for OpenVPN off my website
• Possibility to get hardware acceleration on the cheap. It is trivial to get OpenVPN to work with an SSL library which has via padlock support. A padlock capable motherboard is around 120$. This theoretically gives you 50Mbit hardware accelerated AES. Practically - see caveats
• Ease of debug and understanding. It provides you with the notion of interface. You can tcpdump it, collect stats, check its status, you name it. You do not get any of that with IPSEC.

Caveats:

• OpenVPN will copy from userland to kernel and back to perform its task. As a result it has a speed limit per client which cannot be worked around. It is a fundamental limitation and is around 5MBit per client (multiple clients bandwidth grows as a log of the number to a total of around 15-20MBit). For a distributed installation or road warriors this may prove to your advantage, because no single client can eat all the resources. There is always some resource to go around. If you want higher speeds on a single encrypted point to point link you are better off with IPSEC transport mode overlay of IP-in-IP or IPSEC overlay of PPTP.
• OpenVPN route mechanism has minimal error checks and will bugger up your routing table majestically of you decide to do something really fancy. If you want to run a large distributed infrastructure you have to run quagga and use OSPF or RIP for routing. Either works fine provided that you can do them and you use peer-to-peer mode of OpenVPN. This also allows you to interoperate nicely with any failover within your network and this is something you never get out of IPSEC.
• You cannot use the Server mode of OpenVPN along with routing protocols. Actually I think that there are some fixes in the Quagga CVS head that will allow this but I will advise against this. This is a mode for road warriors. If you want infrastructure you better set your tunnels properly as peer mode ones.

I used to have a similar list to yours, but most of it is in storage now. I have reduced it to a XP3200+ with a RAID array which is used for storage and thin clients like this: http://www.sigsegv.cx/hp-thin-client.html for the actual use. This or various Via EPIA systems. 5-15W power consumption. And most importantly - very very very quiet.

SQL does not allow adding and subtracting date types. I think this is part of the ANSI spec, but I may be mistaken. You need to use the interval ops.

Example: http://www.sigsegv.cx/exim-greylist.html

As far as the checking is concerned I think that 4+ does all checking including invalidating dates like 31 Feb correctly.