I have no clue on the state of the art, as I stopped being a PC repair d00d more than a decade ago.
That said, BACK THEN, ASUS carried a ~$20 premium on a $150 mobo... It also generally performed a little better. And almost NEVER came back.
So, ever since, I have bought only ASUS for myself when I've had component-selection priviledges. No problems, ever. In fact, I still have a Solaris 7/x86 server here that has been running continuously without repair since... Jun 1999? 1998? It's a P2T4 IIRC, with a 400 MHz P-II Celeron in it. Socket 370, slocket, Slot-1.
One of my favourite ASUS boards was the 486 PVI SP3. It had a built-in SCSI BIOS, for use with the ASUS SCSI controller, and was possibly the only board ever made with PCI and VESA Local Bus slots that didn't suck.
I bought one of those in early 1996(?), and was quite pleased with the ASUS SCSI board which replaced my Adaptec 1522 (hooked up to a 1054MB 5400 RPM Fast-SCSI-II Fujitsu disk). I also had an ATI Mach 64 video card for it, and was running an AMD 486 DX4/100 on it. Oh yes, and Sound Blaster 16.
I remember the day I installed Windows '95 on that box, I was totally blown away at the fact that I could drag around the Weezer video (Buddy Holly) in a window, with the animation still playing. The I/O on that box was insane! It was so fast!
(Why does my Athlon running XP seem so much slower?)
I'm assuming it was those specific few years ago when a Taiwanese capacitor company was selling bad caps. These caps had electrolyte in them made with a formula stolen from a Japanese company. Said Japanese company, though, was wise to the industry pirates and slipped them a time bomb.
Those caps made it in *everywhere* -- or so it seemed. And is actually probably why it's so much easier to find Slot 1 and Socket 370 CPUs than it is to find boards to put 'em in.
First of all, the lookup in iptables appears to be O(N), when you use a single rule to block a single IP.
Second, when you have many rules in iptables, it becomes extremely expensive to insert another one. It will take a long time, and no other iptables administrative operation can happen at the same time.
Third, inserting rules with iptables-restore helps but not enough. I also mentioned ipsets as a solution, but that requires patching your kernel. I also don't know if it's good enough or not.
Fourth, 2^32 is not four million, it's four BILLION
Oh, and the OP wants to block on hostnames because they often stay constant. Say you want to move your C&C around, just flip the hostname randomly through 1000 boxes. Piece of cake.
> While it is nice that you can resise the page text and see it grow, it does > take up more space to store the CSS version than the original JPG.
How about an apples-to-apples comparo? That's probably not an uncompressed (dcam-style) JPG -- so let's compress the CSS. Pretty much any browser more recent than Netscape Navigator 2 will handle deflate.
> Seriously, threaded processing in C is damn simple.
No, threads are hard.
I mean, creating and joining threads sure is easy. What's hard is writing correct multithreaded programs. In C, or many other MT languages. But C reveals some additional complexity, especially in the "fully portable" realm, that I would classify as non-trivial:
Under what circumstances can thread 1's loop run more than 500 times?
I'll give you a hint, it requires two CPUs, and only breaks on certain arches.
And there are plenty more non-obvious "gotchas". For example, what happens when one thread holds a mutex and another thread forks, with fork-one semantics, without ever calling exec? What thread receives posix signals? Now consider the case when you're developing MT libraries that fork or catch? Or how about libraries that hold mutexes and the applications fork?
These are all "solvable" problems, but they certainly stretch beyond the "threads in C are easy" threshold.
Wow, you may have just convinced me to upgrade GCCs to get better warnings.
I got nailed 3-4 weeks back with a very strange bug, where I foolishly assumed that "1 32" was 0 (32-bit sparc). Unfortunately, it turns out to be 0xffffffff. Argh.
> Unfortuantely a common attitude is, "the program is screwed anyway > at that point, so who cares?"
I have to admit, I'm one of those guys with that attitude.
On the other hand, I generally only bother not checking the return value if I'm _really_ sure the program is going to crash _soon_ (like within 2-3 lines and no branches after the failed malloc).
Things like
a = malloc(sizeof(int)); *a = 3;
a = calloc(sizeof(*a)); a->member = value;
a = alloc(sizeof(*a)); memset(&a, 32, sizeof(a));
...I would all expect to be safe. OTOH,
a = malloc(64); someFunc(a);
...I would insist on a check unless someFunc() _explicitly_ documented its behaviour in its contract *and* I was able to deal with all of its error conditions, even those cause by passing NULL a.
That said, my second example of what I consider is safe is possibly exploitable under some wierdly wild circumstance. It would involve VERY low memory addresses being mapped in. Or, a VERY large struct. This is a good article, it's made me think of something new.
Unfortunately, there are [rare] times when it is necessary to write code which generates compiler warnings. The most common one I experience is cast-align, for perfectly reasonable reasons (_I_ have made sure the cast promotion is correct, but it is impossible for the compiler to know).
In these cases, it would be nice to have an __attribute__() which says "Suppress this warning". Maybe even which forces the programmer to type in some explanatory text (since I comment every single warning that comes out of my checked-in code).
But for those coders out there who produce code with reams and reams of warnings... gads. And for these which don't, yet "fix" things like const-correctness warnings with stupid casts (instead of fixing the root of the problem).. Shame on you!
1. Restore from backup. No backup? Stay late and re-create it. If not possible, fire the user. He shouldn't have gotten into that boat in the first place.
2. Make the user stay late and reinstall the OS and applications as needed. And rap him on the knuckles with a heavy ruler.
3. Fire the user. You're supposed to keep that stuff on the NAS.
4. That's why God invented IMAP, and why we don't allow users to delete email.
I am no RF expert either, but I have been on the receiving end of WiMax-ish technology, and the jitter was so bad, it was completely unusable for VoIP and even made ssh annoying at times.
This was kit designed to work for up to 10 km (6 miles) and I had line-of-sight to the base station, which was about 150m (500 ft) away.
Sky.. sky.. SkySomething. SkyPilot? Some kind of wierd meshy-network, I was also connected to the "master" tower, not a leaf.
The problem, as it was explained to me, was that it has a collision/backoff algorithm not unlike that of 10-base-2 ethernet ("thin net"). So, the 50 (or so) neighbours I had, plus the leaf towers (2 of them, I think) were causing me to not get "slots" with the master on a timely basis. Hence, introducing jitter.
So, your L2 protocol hypothesis is reasonable from my perspective, although we can eliminate poor radio performance as a direct cause. Changing the radio from broadcast to something like time or code division multiplexing would be a good solution for reducing jitter, but probably causes other problems (like decreased burst bandwidth and range).
My solution? "*sigh* - cancel the wireless link and order me a up a T1"
Wireless is nice because it's easy. But it sure ain't there yet.
> Little Timmy doesn't want to spend any time fiddling with settings to make > his new game work, he just wants to plug it in and go.
To hell with Little Timmy. I'm a senior systems developer with roots in the PC repair field, in the early 90s while I was in school. I am perfectly capable of specifying, purchasing, and assembling a hardware platform suitable for whatever I might want to play.
But you know what? I spend about 40 hours a year gaming. It takes 15 minutes to buy a Wii and some controllers and 10 more to ask to the Wii nerd at Walmart what doesn't suck. That's it. 25 minutes invested. When I want to play games, I DON'T want to piss around installing an OS, patches, making sure Direct X version 18.4 is installed, blah ablah ablah abl h.
PC is *shitty* platform for games because it is _general purpose_. NOBODY wants to come home and work to play.
I don't know what browser you're using, but CPU-sucking javascript should get stopped in its tracks by firefox. When the branch callback counter hits some magical number, you should get an alert that says something like "the script you are running sucks ass. abort or continue?"
Quite a few of those were reserved because they were Java reserved words, and they didn't know how Java and Livescript were going to "merge". It's just a happy coincidence that class was in there.
Slashdot Mirror
You need two computers and two cameras. You sit between them and point each camera so they can see both you and another computer.
Simple!
Works best with LCD screens.
I have no clue on the state of the art, as I stopped being a PC repair d00d more than a decade ago.
... Jun 1999? 1998? It's a P2T4 IIRC, with a 400 MHz P-II Celeron in it. Socket 370, slocket, Slot-1.
That said, BACK THEN, ASUS carried a ~$20 premium on a $150 mobo... It also generally performed a little better. And almost NEVER came back.
So, ever since, I have bought only ASUS for myself when I've had component-selection priviledges. No problems, ever. In fact, I still have a Solaris 7/x86 server here that has been running continuously without repair since
One of my favourite ASUS boards was the 486 PVI SP3. It had a built-in SCSI BIOS, for use with the ASUS SCSI controller, and was possibly the only board ever made with PCI and VESA Local Bus slots that didn't suck.
I bought one of those in early 1996(?), and was quite pleased with the ASUS SCSI board which replaced my Adaptec 1522 (hooked up to a 1054MB 5400 RPM Fast-SCSI-II Fujitsu disk). I also had an ATI Mach 64 video card for it, and was running an AMD 486 DX4/100 on it. Oh yes, and Sound Blaster 16.
I remember the day I installed Windows '95 on that box, I was totally blown away at the fact that I could drag around the Weezer video (Buddy Holly) in a window, with the animation still playing. The I/O on that box was insane! It was so fast!
(Why does my Athlon running XP seem so much slower?)
He said "a few years ago"
I'm assuming it was those specific few years ago when a Taiwanese capacitor company was selling bad caps. These caps had electrolyte in them made with a formula stolen from a Japanese company. Said Japanese company, though, was wise to the industry pirates and slipped them a time bomb.
Those caps made it in *everywhere* -- or so it seemed. And is actually probably why it's so much easier to find Slot 1 and Socket 370 CPUs than it is to find boards to put 'em in.
Oh, look, here's a nice wikipedia article about it: http://en.wikipedia.org/wiki/Capacitor_plague
..God is a sixist bastard!
First of all, the lookup in iptables appears to be O(N), when you use a single rule to block a single IP.
Second, when you have many rules in iptables, it becomes extremely expensive to insert another one. It will take a long time, and no other iptables administrative operation can happen at the same time.
Third, inserting rules with iptables-restore helps but not enough. I also mentioned ipsets as a solution, but that requires patching your kernel. I also don't know if it's good enough or not.
Fourth, 2^32 is not four million, it's four BILLION
Oh, and the OP wants to block on hostnames because they often stay constant. Say you want to move your C&C around, just flip the hostname randomly through 1000 boxes. Piece of cake.
I don't think you'd want to do that.
My current RBL has about 6.5 million entries, and is extremely permissive. It is also updated bi-hourly.
I sure wouldn't want my machine to traverse a hosts table of 7 million hosts every time I tried to look up a name in the DNS.
Same for your firewall, 7 million entries will cripple iptables. Hell, 30,000 entries causes visible slowness on a dual-core opteron system.
Of course, you might get better performance out of iptables with the ipsets kernel patch. But that's still a damned big list.
Really, it's pretty bloody simple. Hook a POE adapter into a wireless ethernet bridge.
Voila! Power over wireless ethernet.
Well, I think the obvious answer is "Ben Bowder"
I've been sending goatse pics to unsuspecting web-savvy friends all morning. I haven't pulled off an unsuspecting-goatse in _years_!
.html files and pop 'em open in the browser.
I attach them as HTML source inside text/plain MIME sections
Nerdy friends then get annoyed at my email-incompetence, save them as
Whooo hoooo
Now... who else can I goatse?
> While it is nice that you can resise the page text and see it grow, it does
> take up more space to store the CSS version than the original JPG.
How about an apples-to-apples comparo? That's probably not an uncompressed (dcam-style) JPG -- so let's compress the CSS. Pretty much any browser more recent than Netscape Navigator 2 will handle deflate.
Say What?
/. groks utf-8
I don't think
No, threads are hard.
I mean, creating and joining threads sure is easy. What's hard is writing correct multithreaded programs. In C, or many other MT languages. But C reveals some additional complexity, especially in the "fully portable" realm, that I would classify as non-trivial:
Here's a fun one. Under what circumstances can thread 1's loop run more than 500 times?
I'll give you a hint, it requires two CPUs, and only breaks on certain arches.
And there are plenty more non-obvious "gotchas". For example, what happens when one thread holds a mutex and another thread forks, with fork-one semantics, without ever calling exec? What thread receives posix signals? Now consider the case when you're developing MT libraries that fork or catch? Or how about libraries that hold mutexes and the applications fork?
These are all "solvable" problems, but they certainly stretch beyond the "threads in C are easy" threshold.
> PHP [....] (in capability) it resembles a sped-up but limited subset of Perl?
It's interesting to note what people think of other languages depends on what they know.
To me, PHP looks like a JSP-style markup/SSI language with a wierd syntax, with APIs based on the standard C / UNIX libraries.
But then again, I don't know perl.
You know, when Sun started shipping opteron hardware, the sparc stuff didn't vanish into thin air. It's still very much alive and well.
BTW, what white-box linux platform competes with, say, the Sun Fire X4500 + Solaris?
http://www.youtube.com/watch?v=-zQ5RLAyA7w
And they bought Conner about 10 years ago.
:)
I don't know who else, but they've probably swallowed other companies too. Like Control Data. It's the nature of the beast.
That said, a reasonable argument could at least be made that Conner disks are really Seagate disks.
Oh, and don't forget, Maxtor was also a hungry hungry hippo at one point.
Wow, you may have just convinced me to upgrade GCCs to get better warnings.
I got nailed 3-4 weeks back with a very strange bug, where I foolishly assumed that "1 32" was 0 (32-bit sparc). Unfortunately, it turns out to be 0xffffffff. Argh.
> at that point, so who cares?"
I have to admit, I'm one of those guys with that attitude.
On the other hand, I generally only bother not checking the return value if I'm _really_ sure the program is going to crash _soon_ (like within 2-3 lines and no branches after the failed malloc).
Things like ...I would all expect to be safe. OTOH, ...I would insist on a check unless someFunc() _explicitly_ documented its behaviour in its contract *and* I was able to deal with all of its error conditions, even those cause by passing NULL a.
That said, my second example of what I consider is safe is possibly exploitable under some wierdly wild circumstance. It would involve VERY low memory addresses being mapped in. Or, a VERY large struct. This is a good article, it's made me think of something new.
> Sometimes I wish "-WERROR" was GCC's default.
.. Shame on you!
Unfortunately, there are [rare] times when it is necessary to write code which generates compiler warnings. The most common one I experience is cast-align, for perfectly reasonable reasons (_I_ have made sure the cast promotion is correct, but it is impossible for the compiler to know).
In these cases, it would be nice to have an __attribute__() which says "Suppress this warning". Maybe even which forces the programmer to type in some explanatory text (since I comment every single warning that comes out of my checked-in code).
But for those coders out there who produce code with reams and reams of warnings... gads. And for these which don't, yet "fix" things like const-correctness warnings with stupid casts (instead of fixing the root of the problem)
Some cop with a pink mohawk?
1. Restore from backup. No backup? Stay late and re-create it. If not possible, fire the user. He shouldn't have gotten into that boat in the first place.
/var/spool/mail -type f ... -exec grep .. blah blah
2. Make the user stay late and reinstall the OS and applications as needed. And rap him on the knuckles with a heavy ruler.
3. Fire the user. You're supposed to keep that stuff on the NAS.
4. That's why God invented IMAP, and why we don't allow users to delete email.
5. find
6. Fire the user.
*shrug* seems pretty easy to me.
You're saying that computers _typically_ use thermal noise as a source of entropy for random-number generation?
The only one I'm aware of would be the Yamaha DX7 (and their ilk); that's how the random-noise low-frequency oscillator is fed.
I am no RF expert either, but I have been on the receiving end of WiMax-ish technology, and the jitter was so bad, it was completely unusable for VoIP and even made ssh annoying at times.
This was kit designed to work for up to 10 km (6 miles) and I had line-of-sight to the base station, which was about 150m (500 ft) away.
Sky.. sky.. SkySomething. SkyPilot? Some kind of wierd meshy-network, I was also connected to the "master" tower, not a leaf.
The problem, as it was explained to me, was that it has a collision/backoff algorithm not unlike that of 10-base-2 ethernet ("thin net"). So, the 50 (or so) neighbours I had, plus the leaf towers (2 of them, I think) were causing me to not get "slots" with the master on a timely basis. Hence, introducing jitter.
So, your L2 protocol hypothesis is reasonable from my perspective, although we can eliminate poor radio performance as a direct cause. Changing the radio from broadcast to something like time or code division multiplexing would be a good solution for reducing jitter, but probably causes other problems (like decreased burst bandwidth and range).
My solution? "*sigh* - cancel the wireless link and order me a up a T1"
Wireless is nice because it's easy. But it sure ain't there yet.
> Little Timmy doesn't want to spend any time fiddling with settings to make
> his new game work, he just wants to plug it in and go.
To hell with Little Timmy. I'm a senior systems developer with roots in the PC repair field, in the early 90s while I was in school. I am perfectly capable of specifying, purchasing, and assembling a hardware platform suitable for whatever I might want to play.
But you know what? I spend about 40 hours a year gaming. It takes 15 minutes to buy a Wii and some controllers and 10 more to ask to the Wii nerd at Walmart what doesn't suck. That's it. 25 minutes invested. When I want to play games, I DON'T want to piss around installing an OS, patches, making sure Direct X version 18.4 is installed, blah ablah ablah abl h.
PC is *shitty* platform for games because it is _general purpose_. NOBODY wants to come home and work to play.
(PS, are there any good FPSs for Wii?)
I don't know what browser you're using, but CPU-sucking javascript should get stopped in its tracks by firefox. When the branch callback counter hits some magical number, you should get an alert that says something like "the script you are running sucks ass. abort or continue?"
Quite a few of those were reserved because they were Java reserved words, and they didn't know how Java and Livescript were going to "merge". It's just a happy coincidence that class was in there.
IIRC, IIUC, AFAIK, etc.