Resist the urge to start coding and think hard about the problem your program will solve. If it can't be solved without coding, resist again, and design every piece of the program carefully, and, paraphrasing Dijikstra think about LOC's as lines spent, not lines produced.
...that we need the mp3 of books. Not only I can't own 3.500 "real" books (I could afford them, but can't store because simply don't fit on my apartment), but also organizing them with appropiate metadata is trivial.
Only a good backup system is needed, which can be the same you use for your data (which usually is "none", but...), and some planning foreseeing the obsolescence of the format.
This is specially true with "foreign" laptops. In a perfect world, there would be a special VLAN and ESSID for foreign PC's that usually only need Internet access and/or limited access to corporate network. This is doable with adequate equipment, but justifying the effort and hassle of wide 802.1x deploying isn't easy in some companies where IT it's already overloaded of work.
Maemo devices work, and work really well. Are Linux based and are very hackable, which make them very appealing for the gadget lover. Don't know about OpenMoko, but probably is a good platform, too.
If Nokia tablets don't include a phone its probably because Nokia doesn't want to compete with their own NSeries. Why couldn't Google build something similar? They have the money, the best smart guys the money and reputation can buy, and don't need to compete with another device builders. Their are in another business. They only need to provide the middleware to access their web apps.
Bandwidth has been always counted on bits per second not bytes, so there is no reason for using base 2 notation there(never has been). Changing Mbps to MBytes/sec would confuse users more than anything (my ADSL has been downgraded from 12 to 1.43!!!)
Amazon S3 & EC2 are revolutionary, but at some point, it's a reasonable next step. The only big drawback of EC2 is the lack of persistence so it's hard to host a dataserver on there.
But the truly revolutionary service is Mturk. It's about packetizing tasks for humans! not for computers.
in a presentation from Randal L. Schwartz (yes, the perl guy). Well, really isn't the same, it's just the oppossite, make secondary MX unavalaible(temporary error), and trap non-compliant hosts who should have checked primary first (spammers do it because secondary MX usually have lesser defences). It's funny to see how such different aproaches reduce spam. Check out his presentation You had me at HELO
With frame-relay traffic shaping, I meant adaptative frame relay traffic shaping, so adjusting to cir when your carrier starts to drop packets. Anyway, your example is a good example that commodity hardware can do things that couldn't some years ago (no more pricey Sun hardware for web serving, and no more pricey Cisco hardware for "simple" routing).
Damn! At least someone who knows whats talking about. A PC based router is OK and a really money-saving alterntive for some situations(and I would use OpenBSD instead of Linux on them), but definitively there are things it cann't do. I wonder if there is someone doing frame-relay traffic shaping on a PC with a sangoma card, or L2 QoS or LFI or matching by protocol(NBAR) or... And that's only on the low-end
Unfortunately, I can't survey my spam, because is near to 0 (well, it's a toy system, 500 users, but are lots of organizations like mine that get lots of spam). OpenBSD's spamd with greylisting & blackllisting(spews1) & spamtrap does the job near perfectly. Other tricks like trapping connections to secondary MX while primary is up can be very effective, also.
I think that the kind of spam you describe can't the more common at all. ISP's can rate-limit their customers, and if their main mailserver gets into blacklists they may get into trouble, so I'am sure they track zombie's IP which use their SMTP relay. Besides, SMTP AUTH headers give a lot of info about who's owned.
NetBSD has features that others don't and in some aspects is innovative(or at least different), so it's valuable(for its own users and for the whole OSS "universe"). What we don't need is the zillionth Linux distro, which just repackages applications in a different way.
Related with this, this book shows how wireless can help to improve things in those countries, apart of being a very practical guide to wireless networking. A few miles bridge can be used to share a VSAT connnection, that would be completly out of budget otherwise.
Not only focuses on technical issues, but also in how to make self-financiable and self-mantenible infraestructures. An excellent read.
Yeah, it has some quirks. But has excellent documentation, milters, ldap routing support, advanced queue management and address rewriting features(it's 100% configurable if don't mind getting your hands dirty), it's security record is not that bad[1].
I run it on OpenBSD with spamd and clamav-milter and works like a charm.
(Just for the record, Sendmail X is being rewrited in a Postfix-like fashion.)
[1]look at the latest security bug, that's very hard to exploit!, and is the first in years!
Re:Money's not enough ... but it sure helps
on
Google And Open Source
·
· Score: 2, Informative
really, really helps when we can grab the source for drivers straight from the IBM website.
As long you run SuSe X.X or RedHat Y.Y, with kernel Z.Z for which the RAID controller driver's (closed source) and NIC ones were written to...
Sun, HP or Dell are better than IBM on compatibility, in my humble opinion...
Why is multi-threading faster than the pre-fork model of Apache 1? Because there is less work to do when context-switching threads. A thread shares the same virtual address space with other threads in the process. Changing virtual address spaces is slow because it requires a TLB flush (as well as one or more extra registers to save).
Not every architecture requires a hardware a TLB flush. Some of them (like ia64, I think) maintain a tag called ASID (Address Space IDentifier) so TLB entries can be shared by different processes which share memory pages. Anyway, I always thought that the real performance and scalability benefit between using processes or threads was on task creation and destruction and not on task switching. I'm not saying that a TLB flush on a context switch is negigible but by itself probably is not so important. Could you give any pointers on this?
It's my impression that OpenBSD is in the perfect balance between NetBSD (privileging portability) and FreeBSD (privileging efficiency and software availability).
I think OpenBSD is the less performant and scalable of the three, has less ports and suffers at high loads much more than the others. But it has better security defaults and pf is great. Don't you agree?
Yes, but you can't use putty for serial connections. I use Teraterm for that purpose because I prefer it over hyperterminal (how do you send a BREAK with that?).
I've checked for first time the 2.6.x series, and the first impression was a complete disappointment. Intensive I/O completely freezes the machine, and performance is awful. For example, a simple "dd if=/dev/zero of=verybig bs=1M count=300" took a minute and a half in 2.6.1 versus the 11 seconds in a 2.4.22...
I suppose that's not a normal behaviour, and it's caused by the CONFIG_PREEMPT option(I'm compiling again without it), but can anybody who follows the kernel development explain why is this option recommended for the desktop user if its results are so poor? (or why am I wrong and that's not the cause of the problems....)
Slashdot Mirror
Resist the urge to start coding and think hard about the problem your program will solve. If it can't be solved without coding, resist again, and design every piece of the program carefully, and, paraphrasing Dijikstra think about LOC's as lines spent, not lines produced.
fsck. With softdeps you still need fsck, which in large disks may take forever and consume a lot of memory. Background fsck helps, though.
You need to do a "ipv6 install" first. It's installed but not enabled by default(Vista is).
...that we need the mp3 of books. Not only I can't own 3.500 "real" books (I could afford them, but can't store because simply don't fit on my apartment), but also organizing them with appropiate metadata is trivial.
Only a good backup system is needed, which can be the same you use for your data (which usually is "none", but...), and some planning foreseeing the obsolescence of the format.
This is specially true with "foreign" laptops. In a perfect world, there would be a special VLAN and ESSID for foreign PC's that usually only need Internet access and/or limited access to corporate network. This is doable with adequate equipment, but justifying the effort and hassle of wide 802.1x deploying isn't easy in some companies where IT it's already overloaded of work.
Maemo devices work, and work really well. Are Linux based and are very hackable, which make them very appealing for the gadget lover. Don't know about OpenMoko, but probably is a good platform, too.
If Nokia tablets don't include a phone its probably because Nokia doesn't want to compete with their own NSeries. Why couldn't Google build something similar? They have the money, the best smart guys the money and reputation can buy, and don't need to compete with another device builders. Their are in another business. They only need to provide the middleware to access their web apps.
Bandwidth has been always counted on bits per second not bytes, so there is no reason for using base 2 notation there(never has been). Changing Mbps to MBytes/sec would confuse users more than anything (my ADSL has been downgraded from 12 to 1.43!!!)
Amazon S3 & EC2 are revolutionary, but at some point, it's a reasonable next step. The only big drawback of EC2 is the lack of persistence so it's hard to host a dataserver on there.
But the truly revolutionary service is Mturk. It's about packetizing tasks for humans! not for computers.
in a presentation from Randal L. Schwartz (yes, the perl guy). Well, really isn't the same, it's just the oppossite, make secondary MX unavalaible(temporary error), and trap non-compliant hosts who should have checked primary first (spammers do it because secondary MX usually have lesser defences). It's funny to see how such different aproaches reduce spam. Check out his presentation You had me at HELO
With frame-relay traffic shaping, I meant adaptative frame relay traffic shaping, so adjusting to cir when your carrier starts to drop packets. Anyway, your example is a good example that commodity hardware can do things that couldn't some years ago (no more pricey Sun hardware for web serving, and no more pricey Cisco hardware for "simple" routing).
Damn! At least someone who knows whats talking about. A PC based router is OK and a really money-saving alterntive for some situations(and I would use OpenBSD instead of Linux on them), but definitively there are things it cann't do. I wonder if there is someone doing frame-relay traffic shaping on a PC with a sangoma card, or L2 QoS or LFI or matching by protocol(NBAR) or... And that's only on the low-end
when I survey my spam
Unfortunately, I can't survey my spam, because is near to 0 (well, it's a toy system, 500 users, but are lots of organizations like mine that get lots of spam). OpenBSD's spamd with greylisting & blackllisting(spews1) & spamtrap does the job near perfectly. Other tricks like trapping connections to secondary MX while primary is up can be very effective, also.
I think that the kind of spam you describe can't the more common at all. ISP's can rate-limit their customers, and if their main mailserver gets into blacklists they may get into trouble, so I'am sure they track zombie's IP which use their SMTP relay. Besides, SMTP AUTH headers give a lot of info about who's owned.
IronPython threads can take different CPU's in SMP systems? Does anybody knows?
NetBSD has features that others don't and in some aspects is innovative(or at least different), so it's valuable(for its own users and for the whole OSS "universe"). What we don't need is the zillionth Linux distro, which just repackages applications in a different way.
Related with this, this book shows how wireless can help to improve things in those countries, apart of being a very practical guide to wireless networking. A few miles bridge can be used to share a VSAT connnection, that would be completly out of budget otherwise.
Not only focuses on technical issues, but also in how to make self-financiable and self-mantenible infraestructures. An excellent read.
Yes, and gay marriage is legal, and there's no death penalty, and... it's so unrelated.
Yeah, it has some quirks. But has excellent documentation, milters, ldap routing support, advanced queue management and address rewriting features(it's 100% configurable if don't mind getting your hands dirty), it's security record is not that bad[1].
I run it on OpenBSD with spamd and clamav-milter and works like a charm.
(Just for the record, Sendmail X is being rewrited in a Postfix-like fashion.)
[1]look at the latest security bug, that's very hard to exploit!, and is the first in years!
As long you run SuSe X.X or RedHat Y.Y, with kernel Z.Z for which the RAID controller driver's (closed source) and NIC ones were written to...
Sun, HP or Dell are better than IBM on compatibility, in my humble opinion...
SPARCs are supposed to be multicore soon
SPARC's are multicore now (dual core). They are supposed to be massively multicore soon(eight cores per die/four threads per core on 2006-1Q).
Oh, you mean Red Hat Database Server, aren't you? ;-)
Seriously, it can be a great contender for SQL Server if it gets(more) vendor support.
Why is multi-threading faster than the pre-fork model of Apache 1? Because there is less work to do when context-switching threads. A thread shares the same virtual address space with other threads in the process. Changing virtual address spaces is slow because it requires a TLB flush (as well as one or more extra registers to save).
Not every architecture requires a hardware a TLB flush. Some of them (like ia64, I think) maintain a tag called ASID (Address Space IDentifier) so TLB entries can be shared by different processes which share memory pages. Anyway, I always thought that the real performance and scalability benefit between using processes or threads was on task creation and destruction and not on task switching. I'm not saying that a TLB flush on a context switch is negigible but by itself probably is not so important. Could you give any pointers on this?
It's my impression that OpenBSD is in the perfect balance between NetBSD (privileging portability) and FreeBSD (privileging efficiency and software availability).
I think OpenBSD is the less performant and scalable of the three, has less ports and suffers at high loads much more than the others. But it has better security defaults and pf is great. Don't you agree?
Yes, but you can't use putty for serial connections. I use Teraterm for that purpose because I prefer it over hyperterminal (how do you send a BREAK with that?).
My solutions for that problem:
$ cd
$ find . -type f >
I've checked for first time the 2.6.x series, and the first impression was a complete disappointment. Intensive I/O completely freezes the machine, and performance is awful. For example, a simple "dd if=/dev/zero of=verybig bs=1M count=300" took a minute and a half in 2.6.1 versus the 11 seconds in a 2.4.22...
I suppose that's not a normal behaviour, and it's caused by the CONFIG_PREEMPT option(I'm compiling again without it), but can anybody who follows the kernel development explain why is this option recommended for the desktop user if its results are so poor? (or why am I wrong and that's not the cause of the problems....)