(Oh, to be a freshman again. To take a "programming" class. To never have heard things like "this implementation is O of log n" or "NP complete" or "software cost estimation" or "preemptive fixed priority scheduling"...)
The only assignment I remember from my first programming class was one in which we read in stuff from a file into a linked list, printed it forwards and then printed it backwards. The abstraction of the linked list was so cool, and when it actually worked I felt like king of the nerds (little did I know the horrors to come).
When I was at CMU, there was one intro to programming class, and it was no fun for anyone. Now they've broken it up into people-who-might-take-another-CS-class, and people-who-don't-like-smelling-like-the-cluster, hence a class that is very light on fun and heavy on syntax and object oriented garbage, and one light on programming and heavy on pointy clicky fill in the blanks and make a game happiness.
stepping onto my soapbox:
While we're talking about intro classes, I think everyone who is going to take any additional classes in computer science, especially in the systems area, should take their first class in C, and it should be no fun. Every now and then you can toss them something fun, but learning the discipline of malloc/free, strncmp, etc., will serve you so well when you get to do object-y type computer science stuff. Writing good code, in a scientific or engineering sense, is just like learning to use UNIX - if you didn't suffer, you didn't learn. And if you get to new/delete or just new and then forget about it, you never learn the discipline that writing good code demands.
XM's two satelites are in geostationary orbit, one towards the East coast, one towards the West. You have line of site to both of the all the time (well, probably). The only issue here is that since they're geostationary over the equator, that angle gets a little iffy in places like Seattle, where the satelites are always low on the horizon, and thus more easily blocked by buildings, CowboyNeal, etc. This, however, makes it easy to set up ground based repeaters because you can point the ground repeaters at a satelite and leave them alone.
Sirius' three satelites are in elliptical orbits, and two of the three are over the continental US at all times. The orbits make the angles better (less likely to be blocked by building because the satelite is more likely to be overhead, even in Seattle), but makes doing ground based repeaters hella hard. Sirius rents bandwidth on K-band IIRC to beam signal to the ground based repeaters, which is more expensive and more complicated, but works nonetheless.
That third satelite doesn't do much for reliability. If you lose it, you're going to have areas of the country not getting signal for a good portion of the day, which isn't much better than having portions of the country not getting signal most of the day in the case of XM.
And as far as being money hungry, IIRC these are both publicly traded companies with corporate partners. They both want to make money, and neither of them has your best interests at heart no matter how good their marketspeak is. There is no good guy here. You can morally oppose Clear Channel, and XM by extension. Go ahead. Just remember that its your opinion, and you'll be fine.
and I love it. I still use the minidisc player in my car, but I'd say at least 75% of the time I listen to XM. I can't really talk about Sirius because I don't have it in my car, but I am very pleased with my XM service.
A couple of things to think about:
1. Commercial free - not as important as I would have thought. Yes, lots of channels have commericials. I thought that breaking up the music like that would have annoyed me, but it didn't. I either listen to the commercial, or change the channel, just like TV. Don't be afraid of XM because it has more commercials.
2. If you're afraid of Clear Channel, don't listen to "20 on 20" or KISS-FM from LA. I doubt that Clear Channel is going to mandate a Britney Spears quota on XMU, Liquid Metal, or Unsigned, for example. And some of the corporate content is worth listening to. CNN en Espanol, ESPN Radio, Fox Sports Radio, Sporting News Network, and NASCAR Radio are all on my rotation. How can you not want 24 hour coverage of NASCAR? (Wait, don't answer that. I know I'm a redneck. Get over it.)
3. Don't worry too much about audio quality. Just as high bit rate MP3s still sound like MP3s, satelite radio is going to sound like satelite radio. I would say that the sound quality is generally more consistent than the FM stations around here, and richer than the AM stations, but its not like a CD or MD. I don't notice many digital artifacts on the music stations, and even less on the talk stations (although the bumper music for ESPN Radio's Sportcenter sounds pretty nasty, but that's not a deal breaker for me), but I do notice them. And music that was recorded with too much bass then mixed with too much bass will never sound bass-y enough, no matter how much I play with my equalizer. But the variety of options available makes up for any percieved shortcomings in the audio quality.
4. XM Comedy is worth 10 bucks a month all by itself.
When I was still in school I tried to figure out some good way of being able to work on my research project at home and at school, or at least massage the code and the data in both places.
Being an engineer, I thought of a bunch of ways of setting up complicated distributed ways of doing this, but settled on just leaving the data in one place, and SSH'ing to that box.
The benefits of keeping it simple were:
1. No new work, which is good for the lazy^H^H^H^Hefficient among us. 2. Data coherency. If its only ever in one place its hard to mess up. 3. Backups are easy, since you're only backing up one data set. 4. Did I mention no new work?
As much as data sharing on a heterogenous network would have been nice (Linux box at home, Suns in the lab, Windows at my parent's place, iBook in my backpack), the marginal utility of that data sharing was low compared to the marginal cost of actually doing the work to make it happen.
My vote is for keeping the data in one place and remembering how much you love the terminal. Not a sexy solution, but it works.
For whatever else I learned in college, I learned the most from the capstone courses I took my senior year. I was an ECE at CMU, but took a capstone in ECE and the equivalent in CS. Both were big project courses (Real Time Computer Controlled System Design in ECE and Operating Systems in CS) and both nearly killed me. But I can honestly say that I learned so much by being forced to work on a semester length project.
If you go somewhere and ask about a capstone course, and they look at you funny, ask if there's a course that you take that your whole academic career has been preparing you for, or some sort of big final project where you have to creatively use your skills as a scientist and as an engineer. That's what people do out in industry, anyway, so it should be part of the curriculum.
I'd also ask about what faculty research that the department head is particularly proud of. If its something that interests you, this place would probably be a good fit. If not, you might want to look elsewhere.
Coda is a distributed file system descended from AFS2. Its particularly for things like disconnected operation for laptop users or during network outages, etc.
http://www.openafs.org
AFS is the mother of all distributed file systems. Well, maybe not the mother, but at least the big brother. AFS is not the easiest distributed file system in the whole world to set up, but it is worth every second of setup time if for nothing else than aggressive caching and excellent bandwidth utilization, IMHO.
I am currently using (and used to work for) Timesys.
They have a bunch of BSPs for PowerPC boards. I don't know about VME support, mostly cause I'm working on something on a PCI bus right now.
Couple of cool things about the Timesys Linux kernel:
(1) Fully preemptible kernel (2.4 series, and not the Montavista-derived one that its in 2.5);
(2) Schedulable interrupt handlers and bottom halves (like IRQ7 is a separate thread);
(3) low worst case interrupt latency (70us on a 700MHz Pentium is what the data sheet says, which isn't as good as say 15us on a traditional RTOS, but that 70us is for a real Linux interrupt or process, not one under RTAI or another real time kernel);
(4) CPU and network reservations - so your real-time processes can request that, for example, 3 out of every 18 milliseconds be reserved on the CPU so that its guarenteed to meet its deadline, etc.
They also have a bunch of simulation and modeling tools so you can do things like RMA, etc., on more complicated systems, etc.
1. It depends on the product. Some days, I feel like a code monkey. Or a test monkey. And one of the things that gets me through that "dead-end" feeling is that I feel connected to the program I work for. I work for a defense contractor, and knowing that my code helps, in one way or another, to keep people safe. I don't think I could put up with being a coder if my product was just a bunch of reorganized ones and zeros.
2. It depends on the company. Some companies actually have technical advancement tracks. When I interviewed for my current job, and when I interviewed at SGI, both companies made a big deal about how they had a technical advancement track. Some people want to stay technical, but they don't want to be junior code monkeys when they're 35. My boss still writes code, but he does a lot of other stuff, a lot more design. In that sense, being a coder isn't a dead end as long as you have the opportunity to advance *and* stay technical.
3. About ageism - I don't know about the rest of the world, but in the defense industry, there's a very real sense that I should put up with 80 hour weeks and low pay because everyone else did it when they were young. In the early 90s, they all had to work *way* to much overtime just to keep their jobs. If you were 35 and had 4 kids and a wife and wanted to be a junior coder, there's no way they'd keep you cause they can't abuse you. So, again, if you work for a company where you can stay technical and move out of the junior coder positions, you don't have to worry. Not that this a good system, but its the way it is and no one consulted me before making the rules:-)
So, I guess that was a really rambling way of saying that it depends on who you work for, and what you're working on. It seems like you have to be on your toes to make sure that you end up somewhere where being technical isn't a dead end.
Re:There's no such thing as a "deconstructionist"
on
Globalism Post 9/11
·
· Score: 1
deconstructive method (not "movement"), which has nothing to do with nihilism
I totally agree. I guess my point was that some people take Derrida out of context and then use it justify nihlism. I guess I didn't say that very well.
Based on your rambling post I can tell you've never read Derrida (and probably won't)
I do have a tendency to ramble incoherently. I apologize for that. Its worse in person. And I did read Derrida, but it was a long time ago. I probably shouldn't have brought it up. It didn't really add much to my rambling anyway.
What you're saying may have relevance (though I don't see it)
Sorry about that. Katz inspires the worst in me. I was trying, obviously not well, to say that I'm disappointed to see another sophisticated examination of the dangers of globalism rather than something more constructive. Sorry that I obviously didn't say that well.
Deconstructionist view of the universe
on
Globalism Post 9/11
·
· Score: 4, Interesting
Katz already answered his own question, "Is globalism good or evil?" by the very context of his remarks here. He pits globalism as the necessary evil against religous fanaticism by making the rather remarkable leap that countries unwilling to bow to the will of the modern market will undoubtedly spin out in a blaze of religiosity.
Antiglobalists, and Katz to some extent, fall prey to the currently very vogue deconstructionist view of the universe. In that sense, the only proposal of their vitriolic spew is to attack the organic unity of any tradition or political philosophy that the avante garde determine is their next target. The great problem with adopting a Derrida-esque view of the universe is that you aren't left with much but nihlistic fatalism and a sense of martyrdom. There's an article in the January/February issue of Foreign Affairs that points this out perfectly. The author (whose name escapes me at the moment) states that antiglobalists make the assumption that desconstructionism (a philosophical movement that sprung out of a reaction to formalist literary theory) should not be considered to be a more appropriate or humane or sanctified way of viewing the universe than economics, at least not a priori. His point is that deconstructing globalism doesn't necessarily get you anywhere, and its not even a necessarily appropriate thing to do.
So Katz secures his place in the vanguard of populist philosophy by lamenting the evils of globalism while recognizing its pacifying effect on populaces that, in Katz view, are likely to succumb to religious fanaticism. We all admire the irony and struggle in Katz' voice. Lets all have a quiet moment and think about what a great writer Katz is.
The only problem is that Katz' deconstruction of globalism hasn't left us with anything productive. The net gain to the universe is zero. No new knowledge has been propogated, no new thought inspired - just insipid moaning and ranting and raving.
All I'm asking is that when we discuss matters of such great importance that our goal be to synthesize some new rational thought that actually produces a net gain for the universe. If we discuss globalism, let's discuss ways of mitigating its faults rather than eloquently rehashing all of the arguments against it.
Last week the US scored its third straight hit-to-kill intercept, this one discriminating amongst a group of decoys.
We've been sending a lot of money on missile defense. We're starting to see the fruits of that labor. I just think its funny that when people were debating feasibility, its the biggest news of the day. But when the engineers start to make it work, it doesn't even make the evening news.
Having someone take ownership of an Altivec-aware toolchain is fantastic. Thank you, Redhat. The community, especially those of us who use Linux on PPC systems, thank you.
Now, as far as the untapped power of Altivec, here's the slightly off-topic problem.
To write Altivec code, you need a toolchain of compilers and linkers that understand Altivec. Those compilers won't change your code to use Altivec, but will permit you to do so. This is not a trivial matter to say the list, mostly because the Altivec ABI is difficult to maintain in a compiler because, for instance, it defines vector types.
The only thing that will truly tap the power of Altivec is auto-vectorization, eg. you write slow, unoptimized code with no knowledge of Altivec, and the compiler does it for you. This, as compiler writers know, is the holy grail of vector compilers. Apple implemented some auto-vectorization in its gcc, which required calls across the front-end/back-end boundary, which obviously can't be accepted outright into the FSF tree, hence the lack of good Altivec support in gcc for Linux.
The real issue is that even if you can write good code to make gcc autovectorize for this specific rev of Altivec, its an even less pleasant task to abstract that away so that you can have some starting place for autovectorizing on other platforms (MMX and whatever its called today, 3DNow!, etc.) or the next generation of Altivec.
If Redhat puts even a little development effort into that effort, the benefit to the open software community as a whole would be amazing.
I live in Arizona, so I will be contacting Senator McCain, who is also on the Commerce Committee. And I'm going to tell him something very simple: I am a citizen, not a consumer. I consider my rights as a citizen far more important than my desires as a consumer, and it would be nice if my elected representatives did the same.
No matter what possible benefit I could possibly gain, as a consumer, from the implementation of the SSSCA (if there even are any, which I doubt), those benefits would never be worth the rights I will loose as I citizen.
I agree. In many cases, I imagine it will be relatively easy to do. And there will be cases that it will really suck. But even assuming its moronically easy on every platform, you still have to do it. And someone has to maintain it. And when Ximian tries to track the spec that Microsoft will change as soon as Ximian gets up to the current spec, someone will have to mod it. All the time that gets spent on keeping the CLR right could be spent on the applications that people are trying to build.
All I'm saying is that a CLR type deal adds a lot of complexity to the system. I really do hope its worth it in the end because it'll be good for everyone involved.
I'm just suggesting that maybe some of us in the free software community should put our heads together to come up with ways of getting these kinds of benefits *without* increasing the complexity of the system.
Miguel's argument can be boiled down to this: (1) writing big applications sucks because complexity grows geometrically with each line of code, and (2) integrating code written in different languages sucks because complexity grows geometrically with each line of code in either language. Basically, Miguel is fighting the same fight that every software engineer has faced since the beginning of time. Complexity grows much faster than anyone can handle, and as soon as you let heterogeneity into the equation, you're basically screwed.
The only problem that a CLR supposedly solves is the maintanence of the bindings. Instead of binding Gtk to perl and python and ada and C and C++, etc., you bind it in a library in the CLR. Except that to access that new CLR binding, you need to have perl and python and ada and C and C++ compilers that target the CLR, which is certainly a more glamorous job than maintaining bindings for every language under the sun, but is *WAY MORE* complex.
Basically, the CLR is middleware for the desktop. It does nothing to decrease the complexity of the system, it just shifts some of the complexity to another software engineer. Applications get easier to write, but new compilers need to be written and maintained.
When Microsoft's writing the compilers and you're shelling out the cash, you're only responsible for your piece of it - the application. Obviously this is good for you. But the free software community is responsible for all of it, from compilers to run times, to new bindings, to applications. *We* have to do it all. I wonder if Ximian will really benefit from dispatching software engineers to work on Mono when they could be working on the applications. Companies that buy stuff from Microsoft don't have to send software engineers to work on Mono, but free software projects will "lose" engineers because they'll have to work on Mono, not their respective projects.
The challege that software engineers face in the future is constructing systems that actually reduce the complexity of applications, rather than just shift the complexity elsewhere.
Amazing how the word "breakthrough" can be abused.
Intel announced that they are going to go ahead and push their own high-k dielectric and modified silicon-on-insulator, which they took their time to refine instead of pushing this kind of stuff into fabs early (like IBM and AMD). That's it. They did the same with copper interconnects, waiting for.13 micron processes, IIRC.
There's nothing fantastically new, especially in the press release, except that they did it themselves instead of liscensing it. These aren't the droids you're looking for.
As others have noted, there's no way for a microkernel to be as speedy at flipping bits around as a monolithic kernel, copying between address spaces and everything. Apple attempts to mitigate some of those costs by keeping all their Mach threads in one address space, IIRC, but even with that speed up there's still some overhead.
But that doesn't mean that microkernels suck.
Apache doesn't serve static pages as fast as other web servers. It doesn't serve dynamic content as fast as some servers. But people use Apache for other reasons, things like configurability, extensibility, and support. And because the only thing you *can't* do with an Apache module is make babies.
Microkernels are interesting to computer scientists because they allow abstraction in the kernel, and God only knows that there's no word that computer scientists like more than "abstraction". Microkernels, for all there faults, are just plain prettier. And as research continues into microkernels and how to mitigate their many flaws, there might come a time when the extra processing they require might be worth it. Maybe all the abstraction and objectiness will be worth it to some system designer in the future.
At some point, there may be people who will be willing to trade some latency and throughput for extensibility and configurability in their kernels. They might be willing to trade some clock cycles for the ease with which they can implement different security policies, ala HURD. The point is that not everyone needs the same kernel, and not everyone needs the same kind of kernel.
And competition is good for them both. The HURD developers are incouraged to speed up the kernel, thanks to Linux. Linux kernel hackers will eventually desire some of the design niceties of the HURD kernel, they just won't admit it on the LKML.
not to be an engineer...
on
Ternary Computing
·
· Score: 4, Informative
and rain on the computer scientist's parade, but...
The reason that you can't get, and won't for a long time, anything greater than base 2 is that setting and sensing more than two logical levels in a given voltage range is very hard. Those ones and zeros you like to look at and think about discretely are not really ones and zeros, but voltages close to those that represent one and zero, close enough to not confuse the physics of the device in question.
For example, if you arbitrarily define 0 volts to be a 0 and 1 volt to be 1 in an equally useless and arbitrary circuit, and you monitor the voltage, what do you assume is happening if one of your discrete samples is.5? Is it your ternary maybe, or is it the circuit switching from 0 to 1? And what about the case when your manufacturing process introduces errors greater than you expected? What if 1 comes out.75? Is that in the maybe range or the 1 range?
Now, I remember something about double flash memory densities by sensing 4 voltage ranges in each cell, but I imagine the timing precision required to do that correctly is orders of magnitude easier to do (and still a royal pain) than putting ternary logic into a modern microprocessor (with tens of millions of transistors, implementing everything created in the entire history of computing that might be even marginally useful so that you can 3 more frames per second in quake3).
Too bad we aren't learning from the British and Soviet mistakes.
Yes, a whole sale invasion of Afghani soil with the purpose of controlling the countryside either without [1] air support or precision guided munitions or [2] while fighting an army backed with money and training from another super-power would be stupid. But unless I've been in a coma for a couple of weeks and its not really the 22nd of September, no one has suggested that yet.
Not like I've ever been known to just go off, but one of these days I'm seriously going to have an aneurysm or hemmorage or something if people don't stop assuming that there are only two sides to any story. Our options are not "invade Afghanastan" or "stay at home and be safe". Its not that easy. Not doing anything doesn't make you safe, and doing something doesn't mean sending thousands of people to needless deaths. The issue is a little bit more complex, especially since no military action and millions of dollars in humanitarian aid to most of the Middle East up to September 11 sure did a lot of good at stopping terroism.
As long as there are *governments* that sponsor terrorism, monetarily, with training, or with physical protection, you will not be safe.
I trust the leaders of my country. I trust our military. And if my country calls me to service, you can bet your ass I'll be at the recruiting station in 15 minutes. I'm not willing to sacrifice my freedom so that you can be self-righteous about how much you love peace or how you are so smart since you passed a few history classes and managed to watch CNN. I will sacrifice my life so that we call live free from fear in the liberty our grandparents died for.
I'm interested to see what the influence of Alpha IP will be on Intel core designs. When I took computer architecture at CMU we spent a couple of lectures on why the Alpha was the best thing since sliced bread, as far as microprocessors go.
One of the big things that the Alpha did that was so cool was the branch predictor, which actually implemented two branch prediction algorithms and then had a predictor that watched them both and picked the one that was recently the most correct. Some of that kind of deep knowledge of branch prediction and how to avoid having your long pipeline kill performance would be information that Intel could sorely use on the pentium 4 core, as well as on the Itanic, I mean Inanium, I mean *Itanium*. There we go.
Is anyone else suprised that the G4 core seems so vanilla? The difficulty of making a 4 stage pipeline run at upwards of 733 MHZ on a.25 or.18 micron process is pretty amazing. I'm impressed. I suppose that the embedded focus at Motorola meant that bells and whistes weren't a high priority, but I wonder what kind of performance improvements G4e will demonstrate with a longer pipeline and all.
Technically you don't know how long it takes on a regular microprocessor because of out of order execution and multiple issues per cycles.
And on an async processor, i'd imagine that each instruction has an average latency. That way, you'd know about what should happen.
The clock that the OS uses to wake itself up to make scheduling decisions is completely seperate from the clock signal that is distributed on a cpu chip. The clock signal on a chip is what permits data and control signals to advance from one stage of the pipeline to the next, and thats the clock signal that async logic gets rid of.
The clock that the OS uses to wake itself is a hardware interrupt from a completely seperate place.
Instead of using as just another proxy or webserver, I think it would probably be put to best use as a tool for teaching computer science to little kids. While this unfortunately requires you or someone on staff to learn Irix, that is a nice box, and Irix is a nifty platform. If someone there wants to learn to use it, it could be a really powerful tool for teaching tech skills to kids to whom those skills might be making it out of the poorest counties in Virginia.
Irix, in my experience, was always used for computationaly intensive tasks: graphic, or real time simulation, not webserving or proxy type tasks.
The last part is that the learning curve to get acquanted with Irix, where the developer community is smaller, is unfortunately higher. But if you get any "Learn Unix" book, you should be able to make, but with a good deal of patience.
While I'm inclined to believe all of the Anti-Mac/X-is-evil/GUIs-are-good/Voice-is-the-futu re stuff, I have a hard time getting over the UNIX development model. When we first started using computers for important work, the tools and interface developed over years worth of user input - grep got all of its features because at one point someone actually NEEDED that feature. X is a part of that, in that it developed out of what people needed.
If the Anti-Mac interface were so compelling, there should be someone making one. Could it be that its not quite as terrific as we expect? Could it be that implementing a whole bunch of the Anti-Mac interface is just to different, to difficult, that the current model will suffice for a long time?
Which brings me to X, which is the Anti-Anti-Mac, because while your window-manager/session-manager, etc. might do neat stuff, X is only concerned with where the mouse is (focus), and what the keyboard does. And despite the fact its an ill-suited interface paradigm, we all still use it, and it still evolves because of our needs (witness the growth of 3D acceleration in XFree86 4). While its still an incremental imitation of 30 year old design, it evolved with us.
The short truth is that good user interface, like any other tool, evolves with the needs of the user, not with the desire of the planner.
Slashdot Mirror
(Oh, to be a freshman again. To take a "programming" class. To never have heard things like "this implementation is O of log n" or "NP complete" or "software cost estimation" or "preemptive fixed priority scheduling"...)
The only assignment I remember from my first programming class was one in which we read in stuff from a file into a linked list, printed it forwards and then printed it backwards. The abstraction of the linked list was so cool, and when it actually worked I felt like king of the nerds (little did I know the horrors to come).
When I was at CMU, there was one intro to programming class, and it was no fun for anyone. Now they've broken it up into people-who-might-take-another-CS-class, and people-who-don't-like-smelling-like-the-cluster, hence a class that is very light on fun and heavy on syntax and object oriented garbage, and one light on programming and heavy on pointy clicky fill in the blanks and make a game happiness.
stepping onto my soapbox:
While we're talking about intro classes, I think everyone who is going to take any additional classes in computer science, especially in the systems area, should take their first class in C, and it should be no fun. Every now and then you can toss them something fun, but learning the discipline of malloc/free, strncmp, etc., will serve you so well when you get to do object-y type computer science stuff. Writing good code, in a scientific or engineering sense, is just like learning to use UNIX - if you didn't suffer, you didn't learn. And if you get to new/delete or just new and then forget about it, you never learn the discipline that writing good code demands.
-- steps off soapbox.
XM's two satelites are in geostationary orbit, one towards the East coast, one towards the West. You have line of site to both of the all the time (well, probably). The only issue here is that since they're geostationary over the equator, that angle gets a little iffy in places like Seattle, where the satelites are always low on the horizon, and thus more easily blocked by buildings, CowboyNeal, etc. This, however, makes it easy to set up ground based repeaters because you can point the ground repeaters at a satelite and leave them alone.
Sirius' three satelites are in elliptical orbits, and two of the three are over the continental US at all times. The orbits make the angles better (less likely to be blocked by building because the satelite is more likely to be overhead, even in Seattle), but makes doing ground based repeaters hella hard. Sirius rents bandwidth on K-band IIRC to beam signal to the ground based repeaters, which is more expensive and more complicated, but works nonetheless.
That third satelite doesn't do much for reliability. If you lose it, you're going to have areas of the country not getting signal for a good portion of the day, which isn't much better than having portions of the country not getting signal most of the day in the case of XM.
And as far as being money hungry, IIRC these are both publicly traded companies with corporate partners. They both want to make money, and neither of them has your best interests at heart no matter how good their marketspeak is. There is no good guy here. You can morally oppose Clear Channel, and XM by extension. Go ahead. Just remember that its your opinion, and you'll be fine.
and I love it. I still use the minidisc player in my car, but I'd say at least 75% of the time I listen to XM. I can't really talk about Sirius because I don't have it in my car, but I am very pleased with my XM service.
A couple of things to think about:
1. Commercial free - not as important as I would have thought. Yes, lots of channels have commericials. I thought that breaking up the music like that would have annoyed me, but it didn't. I either listen to the commercial, or change the channel, just like TV. Don't be afraid of XM because it has more commercials.
2. If you're afraid of Clear Channel, don't listen to "20 on 20" or KISS-FM from LA. I doubt that Clear Channel is going to mandate a Britney Spears quota on XMU, Liquid Metal, or Unsigned, for example. And some of the corporate content is worth listening to. CNN en Espanol, ESPN Radio, Fox Sports Radio, Sporting News Network, and NASCAR Radio are all on my rotation. How can you not want 24 hour coverage of NASCAR? (Wait, don't answer that. I know I'm a redneck. Get over it.)
3. Don't worry too much about audio quality. Just as high bit rate MP3s still sound like MP3s, satelite radio is going to sound like satelite radio. I would say that the sound quality is generally more consistent than the FM stations around here, and richer than the AM stations, but its not like a CD or MD. I don't notice many digital artifacts on the music stations, and even less on the talk stations (although the bumper music for ESPN Radio's Sportcenter sounds pretty nasty, but that's not a deal breaker for me), but I do notice them. And music that was recorded with too much bass then mixed with too much bass will never sound bass-y enough, no matter how much I play with my equalizer. But the variety of options available makes up for any percieved shortcomings in the audio quality.
4. XM Comedy is worth 10 bucks a month all by itself.
Just my two cents.
When I was still in school I tried to figure out some good way of being able to work on my research project at home and at school, or at least massage the code and the data in both places.
Being an engineer, I thought of a bunch of ways of setting up complicated distributed ways of doing this, but settled on just leaving the data in one place, and SSH'ing to that box.
The benefits of keeping it simple were:
1. No new work, which is good for the lazy^H^H^H^Hefficient among us.
2. Data coherency. If its only ever in one place its hard to mess up.
3. Backups are easy, since you're only backing up one data set.
4. Did I mention no new work?
As much as data sharing on a heterogenous network would have been nice (Linux box at home, Suns in the lab, Windows at my parent's place, iBook in my backpack), the marginal utility of that data sharing was low compared to the marginal cost of actually doing the work to make it happen.
My vote is for keeping the data in one place and remembering how much you love the terminal. Not a sexy solution, but it works.
For whatever else I learned in college, I learned the most from the capstone courses I took my senior year. I was an ECE at CMU, but took a capstone in ECE and the equivalent in CS. Both were big project courses (Real Time Computer Controlled System Design in ECE and Operating Systems in CS) and both nearly killed me. But I can honestly say that I learned so much by being forced to work on a semester length project.
If you go somewhere and ask about a capstone course, and they look at you funny, ask if there's a course that you take that your whole academic career has been preparing you for, or some sort of big final project where you have to creatively use your skills as a scientist and as an engineer. That's what people do out in industry, anyway, so it should be part of the curriculum.
I'd also ask about what faculty research that the department head is particularly proud of. If its something that interests you, this place would probably be a good fit. If not, you might want to look elsewhere.
http://www.coda.cs.cmu.edu
Coda is a distributed file system descended from AFS2. Its particularly for things like disconnected operation for laptop users or during network outages, etc.
http://www.openafs.org
AFS is the mother of all distributed file systems. Well, maybe not the mother, but at least the big brother. AFS is not the easiest distributed file system in the whole world to set up, but it is worth every second of setup time if for nothing else than aggressive caching and excellent bandwidth utilization, IMHO.
I am currently using (and used to work for) Timesys.
They have a bunch of BSPs for PowerPC boards. I don't know about VME support, mostly cause I'm working on something on a PCI bus right now.
Couple of cool things about the Timesys Linux kernel:
(1) Fully preemptible kernel (2.4 series, and not the Montavista-derived one that its in 2.5);
(2) Schedulable interrupt handlers and bottom halves (like IRQ7 is a separate thread);
(3) low worst case interrupt latency (70us on a 700MHz Pentium is what the data sheet says, which isn't as good as say 15us on a traditional RTOS, but that 70us is for a real Linux interrupt or process, not one under RTAI or another real time kernel);
(4) CPU and network reservations - so your real-time processes can request that, for example, 3 out of every 18 milliseconds be reserved on the CPU so that its guarenteed to meet its deadline, etc.
They also have a bunch of simulation and modeling tools so you can do things like RMA, etc., on more complicated systems, etc.
1. It depends on the product. Some days, I feel like a code monkey. Or a test monkey. And one of the things that gets me through that "dead-end" feeling is that I feel connected to the program I work for. I work for a defense contractor, and knowing that my code helps, in one way or another, to keep people safe. I don't think I could put up with being a coder if my product was just a bunch of reorganized ones and zeros.
:-)
2. It depends on the company. Some companies actually have technical advancement tracks. When I interviewed for my current job, and when I interviewed at SGI, both companies made a big deal about how they had a technical advancement track. Some people want to stay technical, but they don't want to be junior code monkeys when they're 35. My boss still writes code, but he does a lot of other stuff, a lot more design. In that sense, being a coder isn't a dead end as long as you have the opportunity to advance *and* stay technical.
3. About ageism - I don't know about the rest of the world, but in the defense industry, there's a very real sense that I should put up with 80 hour weeks and low pay because everyone else did it when they were young. In the early 90s, they all had to work *way* to much overtime just to keep their jobs. If you were 35 and had 4 kids and a wife and wanted to be a junior coder, there's no way they'd keep you cause they can't abuse you. So, again, if you work for a company where you can stay technical and move out of the junior coder positions, you don't have to worry. Not that this a good system, but its the way it is and no one consulted me before making the rules
So, I guess that was a really rambling way of saying that it depends on who you work for, and what you're working on. It seems like you have to be on your toes to make sure that you end up somewhere where being technical isn't a dead end.
deconstructive method (not "movement"), which has nothing to do with nihilism
I totally agree. I guess my point was that some people take Derrida out of context and then use it justify nihlism. I guess I didn't say that very well.
Based on your rambling post I can tell you've never read Derrida (and probably won't)
I do have a tendency to ramble incoherently. I apologize for that. Its worse in person. And I did read Derrida, but it was a long time ago. I probably shouldn't have brought it up. It didn't really add much to my rambling anyway.
What you're saying may have relevance (though I don't see it)
Sorry about that. Katz inspires the worst in me. I was trying, obviously not well, to say that I'm disappointed to see another sophisticated examination of the dangers of globalism rather than something more constructive. Sorry that I obviously didn't say that well.
Katz already answered his own question, "Is globalism good or evil?" by the very context of his remarks here. He pits globalism as the necessary evil against religous fanaticism by making the rather remarkable leap that countries unwilling to bow to the will of the modern market will undoubtedly spin out in a blaze of religiosity.
Antiglobalists, and Katz to some extent, fall prey to the currently very vogue deconstructionist view of the universe. In that sense, the only proposal of their vitriolic spew is to attack the organic unity of any tradition or political philosophy that the avante garde determine is their next target. The great problem with adopting a Derrida-esque view of the universe is that you aren't left with much but nihlistic fatalism and a sense of martyrdom. There's an article in the January/February issue of Foreign Affairs that points this out perfectly. The author (whose name escapes me at the moment) states that antiglobalists make the assumption that desconstructionism (a philosophical movement that sprung out of a reaction to formalist literary theory) should not be considered to be a more appropriate or humane or sanctified way of viewing the universe than economics, at least not a priori. His point is that deconstructing globalism doesn't necessarily get you anywhere, and its not even a necessarily appropriate thing to do.
So Katz secures his place in the vanguard of populist philosophy by lamenting the evils of globalism while recognizing its pacifying effect on populaces that, in Katz view, are likely to succumb to religious fanaticism. We all admire the irony and struggle in Katz' voice. Lets all have a quiet moment and think about what a great writer Katz is.
The only problem is that Katz' deconstruction of globalism hasn't left us with anything productive. The net gain to the universe is zero. No new knowledge has been propogated, no new thought inspired - just insipid moaning and ranting and raving.
All I'm asking is that when we discuss matters of such great importance that our goal be to synthesize some new rational thought that actually produces a net gain for the universe. If we discuss globalism, let's discuss ways of mitigating its faults rather than eloquently rehashing all of the arguments against it.
Speaking of ballistic missile defense:
Last week the US scored its third straight hit-to-kill intercept, this one discriminating amongst a group of decoys.
We've been sending a lot of money on missile defense. We're starting to see the fruits of that labor. I just think its funny that when people were debating feasibility, its the biggest news of the day. But when the engineers start to make it work, it doesn't even make the evening news.
Having someone take ownership of an Altivec-aware toolchain is fantastic. Thank you, Redhat. The community, especially those of us who use Linux on PPC systems, thank you.
Now, as far as the untapped power of Altivec, here's the slightly off-topic problem.
To write Altivec code, you need a toolchain of compilers and linkers that understand Altivec. Those compilers won't change your code to use Altivec, but will permit you to do so. This is not a trivial matter to say the list, mostly because the Altivec ABI is difficult to maintain in a compiler because, for instance, it defines vector types.
The only thing that will truly tap the power of Altivec is auto-vectorization, eg. you write slow, unoptimized code with no knowledge of Altivec, and the compiler does it for you. This, as compiler writers know, is the holy grail of vector compilers. Apple implemented some auto-vectorization in its gcc, which required calls across the front-end/back-end boundary, which obviously can't be accepted outright into the FSF tree, hence the lack of good Altivec support in gcc for Linux.
The real issue is that even if you can write good code to make gcc autovectorize for this specific rev of Altivec, its an even less pleasant task to abstract that away so that you can have some starting place for autovectorizing on other platforms (MMX and whatever its called today, 3DNow!, etc.) or the next generation of Altivec.
If Redhat puts even a little development effort into that effort, the benefit to the open software community as a whole would be amazing.
I live in Arizona, so I will be contacting Senator McCain, who is also on the Commerce Committee. And I'm going to tell him something very simple:
I am a citizen, not a consumer. I consider my rights as a citizen far more important than my desires as a consumer, and it would be nice if my elected representatives did the same.
No matter what possible benefit I could possibly gain, as a consumer, from the implementation of the SSSCA (if there even are any, which I doubt), those benefits would never be worth the rights I will loose as I citizen.
I agree. In many cases, I imagine it will be relatively easy to do. And there will be cases that it will really suck. But even assuming its moronically easy on every platform, you still have to do it. And someone has to maintain it. And when Ximian tries to track the spec that Microsoft will change as soon as Ximian gets up to the current spec, someone will have to mod it. All the time that gets spent on keeping the CLR right could be spent on the applications that people are trying to build.
All I'm saying is that a CLR type deal adds a lot of complexity to the system. I really do hope its worth it in the end because it'll be good for everyone involved.
I'm just suggesting that maybe some of us in the free software community should put our heads together to come up with ways of getting these kinds of benefits *without* increasing the complexity of the system.
Miguel's argument can be boiled down to this: (1) writing big applications sucks because complexity grows geometrically with each line of code, and (2) integrating code written in different languages sucks because complexity grows geometrically with each line of code in either language. Basically, Miguel is fighting the same fight that every software engineer has faced since the beginning of time. Complexity grows much faster than anyone can handle, and as soon as you let heterogeneity into the equation, you're basically screwed.
The only problem that a CLR supposedly solves is the maintanence of the bindings. Instead of binding Gtk to perl and python and ada and C and C++, etc., you bind it in a library in the CLR. Except that to access that new CLR binding, you need to have perl and python and ada and C and C++ compilers that target the CLR, which is certainly a more glamorous job than maintaining bindings for every language under the sun, but is *WAY MORE* complex.
Basically, the CLR is middleware for the desktop. It does nothing to decrease the complexity of the system, it just shifts some of the complexity to another software engineer. Applications get easier to write, but new compilers need to be written and maintained.
When Microsoft's writing the compilers and you're shelling out the cash, you're only responsible for your piece of it - the application. Obviously this is good for you. But the free software community is responsible for all of it, from compilers to run times, to new bindings, to applications. *We* have to do it all. I wonder if Ximian will really benefit from dispatching software engineers to work on Mono when they could be working on the applications. Companies that buy stuff from Microsoft don't have to send software engineers to work on Mono, but free software projects will "lose" engineers because they'll have to work on Mono, not their respective projects.
The challege that software engineers face in the future is constructing systems that actually reduce the complexity of applications, rather than just shift the complexity elsewhere.
Amazing how the word "breakthrough" can be abused.
.13 micron processes, IIRC.
Intel announced that they are going to go ahead and push their own high-k dielectric and modified silicon-on-insulator, which they took their time to refine instead of pushing this kind of stuff into fabs early (like IBM and AMD). That's it. They did the same with copper interconnects, waiting for
There's nothing fantastically new, especially in the press release, except that they did it themselves instead of liscensing it. These aren't the droids you're looking for.
EEtimes has a better article http://eetimes.com/story/OEG20011126S0031
therefore they are bad.
Right, right.
As others have noted, there's no way for a microkernel to be as speedy at flipping bits around as a monolithic kernel, copying between address spaces and everything. Apple attempts to mitigate some of those costs by keeping all their Mach threads in one address space, IIRC, but even with that speed up there's still some overhead.
But that doesn't mean that microkernels suck.
Apache doesn't serve static pages as fast as other web servers. It doesn't serve dynamic content as fast as some servers. But people use Apache for other reasons, things like configurability, extensibility, and support. And because the only thing you *can't* do with an Apache module is make babies.
Microkernels are interesting to computer scientists because they allow abstraction in the kernel, and God only knows that there's no word that computer scientists like more than "abstraction". Microkernels, for all there faults, are just plain prettier. And as research continues into microkernels and how to mitigate their many flaws, there might come a time when the extra processing they require might be worth it. Maybe all the abstraction and objectiness will be worth it to some system designer in the future.
At some point, there may be people who will be willing to trade some latency and throughput for extensibility and configurability in their kernels. They might be willing to trade some clock cycles for the ease with which they can implement different security policies, ala HURD. The point is that not everyone needs the same kernel, and not everyone needs the same kind of kernel.
And competition is good for them both. The HURD developers are incouraged to speed up the kernel, thanks to Linux. Linux kernel hackers will eventually desire some of the design niceties of the HURD kernel, they just won't admit it on the LKML.
and rain on the computer scientist's parade, but...
.5? Is it your ternary maybe, or is it the circuit switching from 0 to 1? And what about the case when your manufacturing process introduces errors greater than you expected? What if 1 comes out .75? Is that in the maybe range or the 1 range?
The reason that you can't get, and won't for a long time, anything greater than base 2 is that setting and sensing more than two logical levels in a given voltage range is very hard. Those ones and zeros you like to look at and think about discretely are not really ones and zeros, but voltages close to those that represent one and zero, close enough to not confuse the physics of the device in question.
For example, if you arbitrarily define 0 volts to be a 0 and 1 volt to be 1 in an equally useless and arbitrary circuit, and you monitor the voltage, what do you assume is happening if one of your discrete samples is
Now, I remember something about double flash memory densities by sensing 4 voltage ranges in each cell, but I imagine the timing precision required to do that correctly is orders of magnitude easier to do (and still a royal pain) than putting ternary logic into a modern microprocessor (with tens of millions of transistors, implementing everything created in the entire history of computing that might be even marginally useful so that you can 3 more frames per second in quake3).
Too bad we aren't learning from the British and Soviet mistakes.
Yes, a whole sale invasion of Afghani soil with the purpose of controlling the countryside either without [1] air support or precision guided munitions or [2] while fighting an army backed with money and training from another super-power would be stupid. But unless I've been in a coma for a couple of weeks and its not really the 22nd of September, no one has suggested that yet.
Not like I've ever been known to just go off, but one of these days I'm seriously going to have an aneurysm or hemmorage or something if people don't stop assuming that there are only two sides to any story. Our options are not "invade Afghanastan" or "stay at home and be safe". Its not that easy. Not doing anything doesn't make you safe, and doing something doesn't mean sending thousands of people to needless deaths. The issue is a little bit more complex, especially since no military action and millions of dollars in humanitarian aid to most of the Middle East up to September 11 sure did a lot of good at stopping terroism.
As long as there are *governments* that sponsor terrorism, monetarily, with training, or with physical protection, you will not be safe.
I trust the leaders of my country. I trust our military. And if my country calls me to service, you can bet your ass I'll be at the recruiting station in 15 minutes. I'm not willing to sacrifice my freedom so that you can be self-righteous about how much you love peace or how you are so smart since you passed a few history classes and managed to watch CNN. I will sacrifice my life so that we call live free from fear in the liberty our grandparents died for.
I'm interested to see what the influence of Alpha IP will be on Intel core designs. When I took computer architecture at CMU we spent a couple of lectures on why the Alpha was the best thing since sliced bread, as far as microprocessors go.
.25 or .18 micron process is pretty amazing. I'm impressed. I suppose that the embedded focus at Motorola meant that bells and whistes weren't a high priority, but I wonder what kind of performance improvements G4e will demonstrate with a longer pipeline and all.
One of the big things that the Alpha did that was so cool was the branch predictor, which actually implemented two branch prediction algorithms and then had a predictor that watched them both and picked the one that was recently the most correct. Some of that kind of deep knowledge of branch prediction and how to avoid having your long pipeline kill performance would be information that Intel could sorely use on the pentium 4 core, as well as on the Itanic, I mean Inanium, I mean *Itanium*. There we go.
Is anyone else suprised that the G4 core seems so vanilla? The difficulty of making a 4 stage pipeline run at upwards of 733 MHZ on a
Technically you don't know how long it takes on a regular microprocessor because of out of order execution and multiple issues per cycles. And on an async processor, i'd imagine that each instruction has an average latency. That way, you'd know about what should happen.
The clock that the OS uses to wake itself up to make scheduling decisions is completely seperate from the clock signal that is distributed on a cpu chip. The clock signal on a chip is what permits data and control signals to advance from one stage of the pipeline to the next, and thats the clock signal that async logic gets rid of. The clock that the OS uses to wake itself is a hardware interrupt from a completely seperate place.
So, why would we want to do this? Wouldn't it make it easier to develop on the server, where you can control the environment? Isn't the PC dead?
Instead of using as just another proxy or webserver, I think it would probably be put to best use as a tool for teaching computer science to little kids. While this unfortunately requires you or someone on staff to learn Irix, that is a nice box, and Irix is a nifty platform. If someone there wants to learn to use it, it could be a really powerful tool for teaching tech skills to kids to whom those skills might be making it out of the poorest counties in Virginia.
Irix, in my experience, was always used for computationaly intensive tasks: graphic, or real time simulation, not webserving or proxy type tasks.
The last part is that the learning curve to get acquanted with Irix, where the developer community is smaller, is unfortunately higher. But if you get any "Learn Unix" book, you should be able to make, but with a good deal of patience.
While I'm inclined to believe all of the Anti-Mac/X-is-evil/GUIs-are-good/Voice-is-the-futu re stuff, I have a hard time getting over the UNIX development model. When we first started using computers for important work, the tools and interface developed over years worth of user input - grep got all of its features because at one point someone actually NEEDED that feature. X is a part of that, in that it developed out of what people needed.
If the Anti-Mac interface were so compelling, there should be someone making one. Could it be that its not quite as terrific as we expect? Could it be that implementing a whole bunch of the Anti-Mac interface is just to different, to difficult, that the current model will suffice for a long time?
Which brings me to X, which is the Anti-Anti-Mac, because while your window-manager/session-manager, etc. might do neat stuff, X is only concerned with where the mouse is (focus), and what the keyboard does. And despite the fact its an ill-suited interface paradigm, we all still use it, and it still evolves because of our needs (witness the growth of 3D acceleration in XFree86 4). While its still an incremental imitation of 30 year old design, it evolved with us.
The short truth is that good user interface, like any other tool, evolves with the needs of the user, not with the desire of the planner.