Where's the law that says the core layout, or even the die itself, has to be square? Square, or nearly square, might be the most convenient for minimum paths and such. Still, you need to have space somewhere for "between core" control circuits. Even if you lay out the die in a nice square grid, you don't have to make each cell be a core. Getting data lines into the cores in the middle can be an interesting challenge. But then, 100 cores trying to load a word from different locations in RAM all at the same time might be a bit congested. I'd suggest some internal RAM in place of some cores.
If there is a failure of AC... that is, either Air Conditioning OR Alternating Current, you can see a rapid rise in temperature. With all the systems powered off, the latent heat inside the equipment, which is much higher than the room temperature, emerges and raises the room temperature rapidly. And if the equipment is still powered (via UPS when the power fails), the rise is much faster.
In a large data center I once worked at, with 8 mainframes and 1800 servers, power to the entire building failed after several ups and downs in the first minute. The power company was able to tell us within 20 minutes that it looked like a "several hours" outage. We didn't have the UPS capacity for that long, so we started a massive shutdown. Fortunately it was all automated and the last servers finished their current jobs and powered off in another 20 minutes. In that 40 minutes, the server room, normally kept around 17C, was up to a whopping 33C. And even with everything powered off, it peaked at 38C after another 20 minutes. If it weren't so dark in there I think some people would have been starting a sauna.
We had about 40 hard drive failures and 12 power supply failures coming back up that evening. And one of the mainframes had some issues.
Audio is UNDERSTOOD. It is effectively a solved problem in the technical sense. The difficulty of this is that there are still people that think something someone else wants is not worthy of being implemented.
Actually, git isn't even the end of version control. It is certainly an improvement over the past. But just because the basic problem is solved, and understood, does not mean we can't improve it even further. I've found hg to work even better. And I still see ways to potentially improve hg (though I do not personally have the time to dive in and just do it myself).
Someone with a five-digit UID should know that perpetually staying with whatever is developed first means an end to progress. I don't profess that "doing over" makes things perfect. It has the opportunity to make things BETTER (though admittedly, it also has the opportunity to make things WORSE).
As for your selection of Perl 6 for an example... I dismiss your example and replace it with a different language entirely (not specified, so as to avoid attaching a language debate to this thread). My point is that Perl 6 is neither a complete overhaul (if it was, it wouldn't even be called Perl anymore), nor the kind of design process I even propose.
History does have many examples of many ideas reaching their limits, and being replaced by an all new design. It doesn't mean the idea was necessarily bad for its time. In many cases the new design might not have even been practical when it first came out.
Mixing could be done 2 general ways (plus many detailed ways within these 2 categories). One is to allow multiple opens of the audio device node (details: either the hardware can mix multiple audio streams coming into it, or the driver can fake it). The other is a user space program the applications make some kind of connection to (details include what protocol, negotiations, format, priority, etc).
Hardware with a long queue/buffer can help against jitter, dropouts. It would need to have an HPI that allows clearing the buffer so you don't have several minutes of audio still playing when you kill the app. A kernel driver can fake this, too, within the limits of what is appropriate in the kernel (no point if the hardware can do it).
I suggest what is needed is to start over and design a new API and a new protocol... completely separate from any implementations. Then you can have multiple implementations of the API, as needed (at least one per OS that wants to use it).
The API should, of course, be user space (the library implementation then translating to the kernel calls it needs to do, and maybe with kernel call changes if the kernel cannot now deal with the new needs). As for OO, that's fine for binding into an OO language. But the API design should specify its interface in all major languages, whether OO or not (do not just design it for a couple low level languages and hope all the higher level languages implementations cross bind the API the same way). The C++ interface should specify the exact classes while the C interface should be a non-OO specification around an OO design. Again, all the specification needs to come from the one source, or inconsistent variations can happen and ruin it.
The network interface should also be clearly specified before implemented (though not ruling out implementing concurrently with feedback to the protocol design). And there needs to be a renewed discussion of what format (codec) the audio needs to be in for the journey over the network. Ultimately that needs to be something negotiated over the protocol (as well as other things like sample rate, channels, resolution, etc).
And the network method should be designed to work over at least TCP and SCTP. UDP and DCCP would be a plus.
Audio is also a component of media in general. It would be even better if this design is treated as a multi-media design. Then you might have some hope of actually keeping audio and video in sync (something too many multi-media sources have failed to do) for content that has both.
Programs (especially daemons and services) that communicate with other programs (especially over pipes, streams, and network connections) should have a protocol. The protocol should be designed and standardized (even if a one person effort) and the implementation designed around that (and around whatever else it is involved with). Many bugs I have seen in programs are ones where the program failed to correctly implement the protocol. But many more bugs I have seen in programs are ones where the program is also creating the protocol at the same time, and the protocol is whatever happens to come out of the program. You can tell when you have one of these bad boys when the author(s) say to "read the source" when asking about the protocol. So, where is the protocol... documentation (it's not so much the answer, but how this gets answered, that provides the clues to many issues).
You can always override it. The settings allow a default. Most people I have talked to prefer a new tab or new window for links to pages they are going to navigate on and come back. Many people know how to do it as apparently you do. Most don't, surprisingly. And many probably won't know this page needs it at first without the suggestion. I have made such a suggestion before only to be told by several how to make the tag do it (I already know how but they expected me to do it for them). Alas, in Slashdot that is not an option. But I head off the silliest of responses (yours isn't silly).
To get a perspective on the Maldives, start here and then click to zoom in 14 times. I suggest opening the link in a new tab or window (Slashdot code won't let me make the link tag do that for you).
Fix your broken web server. One, it refuses certain browsers. That's just stupid. Two, it mangles the file extension info for the PDF. An oversight maybe, but wrong. Not your web site? Find another.
Still need to block port 25 outbound, even if the Comcast mail servers don't listen to it for email submissions (they do need to listen to it for mail exchange).
When worked at an ISP, I set up the port 25 block to explicitly allow the customers to reach port 25 on OUR mail servers. That should be obvious. It's reaching port 25 outside of the ISP network that is at issue. If the spam goes through the ISP mail server, they can log it, limit it, filter it, or otherwise easily control it there. It's direct connections to the rest of the world that is the issue for spam.
And, of course, this is in addition to other means to stop viruses, like proper protection for Windows users (which is almost all customers).
I agree. Headhunters NEVER get references until the employer, at the end of the interview, asks me to provide them to the headhunter (never happened... those that wanted references asked to have them for themselves). If it was clear to them that I'm not the person they want for the job, they aren't going to ask for them.
BTW, I've also been a reference for a few people. They have asked me if it was OK. I gave them these same instructions.
OTOH, if I'm applying directly (no headhunter) to an employer for a job, I don't have a problem giving them references in advance if they ask. I also give them a link to my LinkedIn page (in the resume).
And I love your signature. I haven't had a good LOL from a/. signature in months, until now.
Through a headhunter is about the only way to get a tech job at a non-tech company, working for pointy-haired bosses that have no clue what you do, but still micromanage and are planning to pin all the problems.... oh nevermind, just don't deal with headhunters.
I put a copyright notice on my Resume. And it's NOT a GNU Documentation License, either. All rights reserved. I tell them to fee free to duplicate to present for suitable jobs, and they can add their letterhead. If they ask (and a couple have), I tell them I don't allow modifications. One asked "what about spelling errors?". I replied "did you find any?". He paused and then said "no". These two never presented me anywhere... which basically meant some other recruiter who wouldn't be a source of damage might. Sometimes you have to stand your ground. But I have an extra basis to sue them if I find they altered the resume in a damaging way.
Slashdot Mirror
Where's the law that says the core layout, or even the die itself, has to be square? Square, or nearly square, might be the most convenient for minimum paths and such. Still, you need to have space somewhere for "between core" control circuits. Even if you lay out the die in a nice square grid, you don't have to make each cell be a core. Getting data lines into the cores in the middle can be an interesting challenge. But then, 100 cores trying to load a word from different locations in RAM all at the same time might be a bit congested. I'd suggest some internal RAM in place of some cores.
describes temperatures using the Fahrenheit scale.
If there is a failure of AC ... that is, either Air Conditioning OR Alternating Current, you can see a rapid rise in temperature. With all the systems powered off, the latent heat inside the equipment, which is much higher than the room temperature, emerges and raises the room temperature rapidly. And if the equipment is still powered (via UPS when the power fails), the rise is much faster.
In a large data center I once worked at, with 8 mainframes and 1800 servers, power to the entire building failed after several ups and downs in the first minute. The power company was able to tell us within 20 minutes that it looked like a "several hours" outage. We didn't have the UPS capacity for that long, so we started a massive shutdown. Fortunately it was all automated and the last servers finished their current jobs and powered off in another 20 minutes. In that 40 minutes, the server room, normally kept around 17C, was up to a whopping 33C. And even with everything powered off, it peaked at 38C after another 20 minutes. If it weren't so dark in there I think some people would have been starting a sauna.
We had about 40 hard drive failures and 12 power supply failures coming back up that evening. And one of the mainframes had some issues.
Audio is UNDERSTOOD. It is effectively a solved problem in the technical sense. The difficulty of this is that there are still people that think something someone else wants is not worthy of being implemented.
Actually, git isn't even the end of version control. It is certainly an improvement over the past. But just because the basic problem is solved, and understood, does not mean we can't improve it even further. I've found hg to work even better. And I still see ways to potentially improve hg (though I do not personally have the time to dive in and just do it myself).
Someone with a five-digit UID should know that perpetually staying with whatever is developed first means an end to progress. I don't profess that "doing over" makes things perfect. It has the opportunity to make things BETTER (though admittedly, it also has the opportunity to make things WORSE).
As for your selection of Perl 6 for an example ... I dismiss your example and replace it with a different language entirely (not specified, so as to avoid attaching a language debate to this thread). My point is that Perl 6 is neither a complete overhaul (if it was, it wouldn't even be called Perl anymore), nor the kind of design process I even propose.
History does have many examples of many ideas reaching their limits, and being replaced by an all new design. It doesn't mean the idea was necessarily bad for its time. In many cases the new design might not have even been practical when it first came out.
Mixing could be done 2 general ways (plus many detailed ways within these 2 categories). One is to allow multiple opens of the audio device node (details: either the hardware can mix multiple audio streams coming into it, or the driver can fake it). The other is a user space program the applications make some kind of connection to (details include what protocol, negotiations, format, priority, etc).
Hardware with a long queue/buffer can help against jitter, dropouts. It would need to have an HPI that allows clearing the buffer so you don't have several minutes of audio still playing when you kill the app. A kernel driver can fake this, too, within the limits of what is appropriate in the kernel (no point if the hardware can do it).
I suggest what is needed is to start over and design a new API and a new protocol ... completely separate from any implementations. Then you can have multiple implementations of the API, as needed (at least one per OS that wants to use it).
The API should, of course, be user space (the library implementation then translating to the kernel calls it needs to do, and maybe with kernel call changes if the kernel cannot now deal with the new needs). As for OO, that's fine for binding into an OO language. But the API design should specify its interface in all major languages, whether OO or not (do not just design it for a couple low level languages and hope all the higher level languages implementations cross bind the API the same way). The C++ interface should specify the exact classes while the C interface should be a non-OO specification around an OO design. Again, all the specification needs to come from the one source, or inconsistent variations can happen and ruin it.
The network interface should also be clearly specified before implemented (though not ruling out implementing concurrently with feedback to the protocol design). And there needs to be a renewed discussion of what format (codec) the audio needs to be in for the journey over the network. Ultimately that needs to be something negotiated over the protocol (as well as other things like sample rate, channels, resolution, etc).
And the network method should be designed to work over at least TCP and SCTP. UDP and DCCP would be a plus.
Audio is also a component of media in general. It would be even better if this design is treated as a multi-media design. Then you might have some hope of actually keeping audio and video in sync (something too many multi-media sources have failed to do) for content that has both.
ALSA isn't working very well for me. How do you make it work to have 3 applications play audio concurrently?
You mean that MP3 won't play now?
Programs (especially daemons and services) that communicate with other programs (especially over pipes, streams, and network connections) should have a protocol. The protocol should be designed and standardized (even if a one person effort) and the implementation designed around that (and around whatever else it is involved with). Many bugs I have seen in programs are ones where the program failed to correctly implement the protocol. But many more bugs I have seen in programs are ones where the program is also creating the protocol at the same time, and the protocol is whatever happens to come out of the program. You can tell when you have one of these bad boys when the author(s) say to "read the source" when asking about the protocol. So, where is the protocol ... documentation (it's not so much the answer, but how this gets answered, that provides the clues to many issues).
We're just better suited to the task.
You can do it in liters and meters if you're not an American.
You can always override it. The settings allow a default. Most people I have talked to prefer a new tab or new window for links to pages they are going to navigate on and come back. Many people know how to do it as apparently you do. Most don't, surprisingly. And many probably won't know this page needs it at first without the suggestion. I have made such a suggestion before only to be told by several how to make the tag do it (I already know how but they expected me to do it for them). Alas, in Slashdot that is not an option. But I head off the silliest of responses (yours isn't silly).
To get a perspective on the Maldives, start here and then click to zoom in 14 times. I suggest opening the link in a new tab or window (Slashdot code won't let me make the link tag do that for you).
And you won't be alone. You just won't know who all the other outlaws are.
(you know what's coming next) ... only outlaws will have anonymity.
So that old 16 MHz machine is still running and you still love it?
... which runs Slackware.
Fix your broken web server. One, it refuses certain browsers. That's just stupid. Two, it mangles the file extension info for the PDF. An oversight maybe, but wrong. Not your web site? Find another.
... what OS has the lowest rate of piracy?
Still need to block port 25 outbound, even if the Comcast mail servers don't listen to it for email submissions (they do need to listen to it for mail exchange).
When worked at an ISP, I set up the port 25 block to explicitly allow the customers to reach port 25 on OUR mail servers. That should be obvious. It's reaching port 25 outside of the ISP network that is at issue. If the spam goes through the ISP mail server, they can log it, limit it, filter it, or otherwise easily control it there. It's direct connections to the rest of the world that is the issue for spam.
And, of course, this is in addition to other means to stop viruses, like proper protection for Windows users (which is almost all customers).
I agree. Headhunters NEVER get references until the employer, at the end of the interview, asks me to provide them to the headhunter (never happened ... those that wanted references asked to have them for themselves). If it was clear to them that I'm not the person they want for the job, they aren't going to ask for them.
BTW, I've also been a reference for a few people. They have asked me if it was OK. I gave them these same instructions.
OTOH, if I'm applying directly (no headhunter) to an employer for a job, I don't have a problem giving them references in advance if they ask. I also give them a link to my LinkedIn page (in the resume).
And I love your signature. I haven't had a good LOL from a /. signature in months, until now.
Through a headhunter is about the only way to get a tech job at a non-tech company, working for pointy-haired bosses that have no clue what you do, but still micromanage and are planning to pin all the problems .... oh nevermind, just don't deal with headhunters.
I put a copyright notice on my Resume. And it's NOT a GNU Documentation License, either. All rights reserved. I tell them to fee free to duplicate to present for suitable jobs, and they can add their letterhead. If they ask (and a couple have), I tell them I don't allow modifications. One asked "what about spelling errors?". I replied "did you find any?". He paused and then said "no". These two never presented me anywhere ... which basically meant some other recruiter who wouldn't be a source of damage might. Sometimes you have to stand your ground. But I have an extra basis to sue them if I find they altered the resume in a damaging way.