I don't see a link to it on the front page anywhere. Maybe it's there and I'm missing it, but I just looked again right now and can't find it. Maybe I'm blind.
That seems worthwhile.
Related bug: it's hard to figure out what the colors mean in firehose (and I clicked on a color, and half the colored stories disappeared, and now I can't get them back).
Other related issue: it's kind of hard to find firehose in the UI, I use Google to find it now.
Direct messaging? Are you kidding me? Promote use of journals more if you want to encourage inter-personal communications that might be off-topic in a discussion elsewhere.
For that to work, you'll need to remove the time-limit on journal comments. Right now, if a journal entry has been around too long, people won't be able to comment on it.
Ah... a 'dwarf' variant. There are defenses against that strategy though.
In fact, it is the original published by A.K. Dewdney himself.
For example, a multiprocess warrior would demolish this, even though it may be several times as long.
Yes, the multiprocessor warrior is the original counter to this, but it can't be too long otherwise it will not demolish this. The dwarf is the thing in the ecosystem that prevents programs from getting too long.
Here is an example of a 'rock' program, it basically overwrites every fifth memory address. The strategy is to quickly pass through memory, hopefully destroying the opponent by blind luck:
dat -1;data, also stores the bombing address add #5 -1;increases the bombing address by five mov #0 @ -2;this is the bomb, it copies the dat line to the address jmp -2;jumpbacktwoinstructions
If you write a program that is only one line long, then this program only has a 1/5 chance of winning.
So the longer the program, the weaker it is against this one. Many complex, interesting programs have been written, only to fall to this bomber.
My theory is, if you could find a way to modify the system that would weaken this strategy, then it would allow longer, and more interesting programs.
I used to like Corewar but the problem is the VM it runs in is too limited in scope for it to be interesting after a while.
Yeah, I've spent time trying to figure out how to make the VM better. I think what you really need is a way to limit rocks, so program size can increase. Right now, any program too large loses quickly to a small, dumb script. And "too large" means larger than 15 lines......
But a game is supposed to be entertainment, Why bother playing a game if you are not actually playing the game?
"Nerd rage is the best rage." When you beat someone in an online game, and they just start raging, saying senseless things to you, and you know they want to throw their keyboard out the window.....
Online team games are even worse, like League of Legends, where you are teamed with a random stranger. Then your teammates will purposely play badly (even attacking their own teammates) just to produce the rage.
Remember that a lot of these people are teenagers, or even pre-teens (some are so young they can't even read the hate you spew at them). They still haven't figured out how to survive in the world, and strange rage entertains them.
There used to be a good amount of original content on Slashdot, things like interviews, book reviews, articles written by Jon Katz. I understand that it may not be worth paying someone to write original content, but why not solicit it from users? I'd love to see more of an emphasis on Ask Slashdot and interviews.
The one that really annoys me is that the Windows version of select(), WaitForMultipleObjects(), has a limit of 64. It's bad enough that the linux version of select() only goes up to 1024 (but at least there are simple ways around that).
The Linux Android drivers used to crash a lot on Windows because they kept hitting that limit. Eventually they fixed it, but with a very ugly hack.
if you are doing device development work or working with different devices which allocate com ports, you may find yourself running out of them and/or applications no longer working because the allocated port number is higher than the range the application handles.
Weird because you would think with more powerful systems, the OS would be updated to handle more ports. No reason to keep the limit artificially low.
It looked so much like layoffs that I thought it was layoffs.
Maybe I misunderstood and they were just trying to get rid of bad programmers. From what I understand, Yahoo had a lot of them.
If they had implemented a 'biosvars' module that understood particular vendor(s) proprietary schemes, then a BIOS system would have the same problem.
That's true, it's technically a UEFI implementation problem, not a problem with UEFI itself. Especially since other boards don't have this problem. (UEFI being complex lends itself to this sort of problem more easily, but there's not really an excuse for the implementation).
The answer is to include a way in the UEFI to restore the default configuration so something like this doesn't brick it irrecoverably.
Rethinking the interface would be nice, but wouldn't stop malicious users.
Because a malicious user shouldn't be able to brick your device that way, either.
There are plenty of ways to avoid accidentally ruining a system this way (including not typing "rm -rf/") but they don't prevent a hacker from destroying your system.
Slashdot Mirror
Screenshot. Maybe it's only a problem on Firefox on OSX? I can check a different OS later........
Ah, I see. It shows up in Safari, but not in Firefox. Browser bug.
I don't see a link to it on the front page anywhere. Maybe it's there and I'm missing it, but I just looked again right now and can't find it. Maybe I'm blind.
That seems worthwhile.
Related bug: it's hard to figure out what the colors mean in firehose (and I clicked on a color, and half the colored stories disappeared, and now I can't get them back).
Other related issue: it's kind of hard to find firehose in the UI, I use Google to find it now.
The "new" metamoderation never made any sense whatsoever.
I didn't know that existed anymore
fwiw I wrote a really nice book review that never got accepted and I'm kind of bitter about that :)
This could be improved somewhat by changing the default sorting order, so older comments appear at the bottom.
at the geographical center of the tech world, in the Mission in San Francisco
this is some kind of cognitive bias or something, because the Mission in San Francisco is definitely not the geographical center of the tech world.
Direct messaging? Are you kidding me? Promote use of journals more if you want to encourage inter-personal communications that might be off-topic in a discussion elsewhere.
For that to work, you'll need to remove the time-limit on journal comments. Right now, if a journal entry has been around too long, people won't be able to comment on it.
Yeap. But if you can think of other ways to make the game bigger, I would be interested, too.
Ah... a 'dwarf' variant. There are defenses against that strategy though.
In fact, it is the original published by A.K. Dewdney himself.
For example, a multiprocess warrior would demolish this, even though it may be several times as long.
Yes, the multiprocessor warrior is the original counter to this, but it can't be too long otherwise it will not demolish this. The dwarf is the thing in the ecosystem that prevents programs from getting too long.
poor kid
If you write a program that is only one line long, then this program only has a 1/5 chance of winning.
So the longer the program, the weaker it is against this one. Many complex, interesting programs have been written, only to fall to this bomber.
My theory is, if you could find a way to modify the system that would weaken this strategy, then it would allow longer, and more interesting programs.
I used to like Corewar but the problem is the VM it runs in is too limited in scope for it to be interesting after a while.
Yeah, I've spent time trying to figure out how to make the VM better. I think what you really need is a way to limit rocks, so program size can increase. Right now, any program too large loses quickly to a small, dumb script. And "too large" means larger than 15 lines......
But if you think your moral outrage will change the world
LOL
But a game is supposed to be entertainment, Why bother playing a game if you are not actually playing the game?
"Nerd rage is the best rage." When you beat someone in an online game, and they just start raging, saying senseless things to you, and you know they want to throw their keyboard out the window.....
Online team games are even worse, like League of Legends, where you are teamed with a random stranger. Then your teammates will purposely play badly (even attacking their own teammates) just to produce the rage.
Remember that a lot of these people are teenagers, or even pre-teens (some are so young they can't even read the hate you spew at them). They still haven't figured out how to survive in the world, and strange rage entertains them.
There used to be a good amount of original content on Slashdot, things like interviews, book reviews, articles written by Jon Katz. I understand that it may not be worth paying someone to write original content, but why not solicit it from users? I'd love to see more of an emphasis on Ask Slashdot and interviews.
I've done it for free, but wasn't accepted.
The one that really annoys me is that the Windows version of select(), WaitForMultipleObjects(), has a limit of 64. It's bad enough that the linux version of select() only goes up to 1024 (but at least there are simple ways around that).
The Linux Android drivers used to crash a lot on Windows because they kept hitting that limit. Eventually they fixed it, but with a very ugly hack.
if you are doing device development work or working with different devices which allocate com ports, you may find yourself running out of them and/or applications no longer working because the allocated port number is higher than the range the application handles.
Weird because you would think with more powerful systems, the OS would be updated to handle more ports. No reason to keep the limit artificially low.
Maybe you're right. Maybe I need to do better at understanding people.
It looked so much like layoffs that I thought it was layoffs.
Maybe I misunderstood and they were just trying to get rid of bad programmers. From what I understand, Yahoo had a lot of them.
If they had implemented a 'biosvars' module that understood particular vendor(s) proprietary schemes, then a BIOS system would have the same problem.
That's true, it's technically a UEFI implementation problem, not a problem with UEFI itself. Especially since other boards don't have this problem. (UEFI being complex lends itself to this sort of problem more easily, but there's not really an excuse for the implementation).
The answer is to include a way in the UEFI to restore the default configuration so something like this doesn't brick it irrecoverably.
Rethinking the interface would be nice, but wouldn't stop malicious users.
If this becomes a standard test case, then you'll see firmware get more resilient to this over time.
The standard test case for UEFI seems to be, "Does it boot Windows?" Those drivers tend to be really buggy.
Because a malicious user shouldn't be able to brick your device that way, either. /") but they don't prevent a hacker from destroying your system.
There are plenty of ways to avoid accidentally ruining a system this way (including not typing "rm -rf