Sounds as though you need to get back to the UNIX mail program. I've sent mail in the past by telnetting straight to the correct SMTP port and typing in the message directly. It's not much harder than using mail (though piping the message into sendmail is even easier...)
Notes 8, now written in Eclipse, also includes an integrated office suite, Lotus Symphony. Written in Eclipse? OK, sounds like they've kept "bloated". (I like Eclipse a lot for working with Java, but dang if it isn't resource hungry!)
I write code that's IN the hardware. An interpreted language? Are you out of your damn mind? Curiously, I've seen an embedded OS/firmware that was written in TCL, back in 2002. Very strange!
Can we collect the DNA of the current Administration preemptively? It'd save a lot of time later on, and we already know they'll qualify for membership of the DB...
FPUs didn't require 100+ GByte/sec dedicated memory systems Quite apart from the fact that speeds were generally lower back then, if you're serious about numerical computation then that sort of speed is of the order that people do want. Or faster. (Googling indicates that 102.4 gigaFLOPS per core is about what the current record is, and the memory bandwidth to support that is distinctly large. Even with PC-class hardware, which typically isn't too efficient on the floating point front, 7.5 gigaFLOPS/core is about what you'll get.)
To cut a long story short, don't take part in a pissing contest with the floating point guys. They'll win.
They should just ban that.exe image file format. Funnily enough, we do just that. Any attachment with an executable name or content type (no, I don't know the exact list) gets squelched in a filter layer that sits between the main incoming SMTP server and the mailbox servers. It irritates only a few people, and yet it saves the bacon of a great many more.
Sometimes the jackboots of fascistic pain are the only sane administration strategy.
Open Office is going to get my vote when it comes time to upgrade here. I've been using Open Office quite a bit recently, and I can't really recommend it for full "production" use. Quite apart from the fact that it handles some graphics in problematic ways, there are a number of other problems that are more serious; in terms of usability there are a number of things (highlighting, notes, tracked change review) that are harder to use than they should be. For example, there's no (obvious) way to print a document with changes in the form that it was changed to; traces of what was removed (especially section headings) always seem to show up.
The best part is the bandwidth throttling, back to 1994 dial-up speeds. I was looking at this yesterday, and it was weird to watch the interlaced GIFs load line by line. (Remember how Netscape used to have a LOWSRC attribute for images, so you could specify a low-res version that could be loaded quickly and displayed while it tried to download the massive, whopping 50K full image?) I remember switching to Netscape very early because it would load images asynchronously, rather than waiting for everything to be loaded before showing me any of it (what NCSA Mosaic used to do at that time). Of course, we now get that sort of annoyance anyway due to the vast gobs of (terrible) javascript inflicted upon us by websites and (especially) advertisers. (Which is one reason why I use NoScript; I don't mind ads too much, but don't slow down my browsing just to show them to me!)
Of course, I can also remember when getting anything (e.g. the Mosaic manual) over the Atlantic was an exercise in frustration too due to the shortage of bandwidth. Bandwidth boosts were the things that saved the internet, back then in '93.
Slashdot is a bit of a weird place, in that I can just imagine the majority of the answers are going to talk about things like Google Summer of Code, or working on an open source project, building your own software, etc...
I'll tell you, those things may help you learn your language or platform better but it will not help you be a better engineer. Unfortunately only time in the trenches does that. In my experience, you want both exposure to open source (so you can learn good habits) and time in the trenches (so you can see what's important). If you're lucky, you can combine those two things in the same job. Most people aren't that lucky; be prepared to put time in on OSS at the weekend. (If you like coding for fun, that's no big deal!)
Pointers are your best friend when you know how to use them. Umm, it's probably fairer to say that pointers are the professional power tools of the computing world. When you need them, they'll do wonders, but they'll just as happily chew big holes in both yourself and passing bystanders. Use with caution, but do use when needed.
Broadband for the USA is a much, much, larger problem than broadband for a tiny european country. Only if you're intent on doing the whole country at the same time. It certainly wasn't done that way in the UK; instead, it was a sustained investment (by companies after being pushed into it very hard by the regulators and government) over many years, and it involved a lot of digging up of streets (well, mostly sidewalks). Sure, at the time it meant a lot of grumbling by various people, but it now means we've got a free market in internet access where there are lots of providers fighting for your custom like rats in a sack. Just what Adam Smith would approve of!
If you (as a nation) want it done, stop finding stupid excuses (and mendacious "regulators") and just fscking do it!
RS-232! Another port killed by (the frankly much better) USB, it had the interesting feature of coming in two widths of connector. The only uses for it I ever had were for connecting my (ultra-fast at the time) 14,400 baud modem, and for programming the Mindstorms brick. (That went to USB with v2, but v1 and 1.5 used RS-232.)
Here's a very quick thought on the possibilities: What if every procedure/function is threaded by default. The compiler then figures out which can possibly lead to race conditions, and adds flagging systems to avoid such issues to those functions only. A multi threaed, well flagged [synclocked] 'reley race' is still faster than a linear solution. What you've just proposed there is deeply magical, you know? The notion of "every function being threaded by default" is odd from the beginning (it makes more sense to think in terms of loops) and compilers are usually terrible at knowing what is safe as they have to get edge cases right even when a higher-level analysis of the program will tell us that in fact those cases are impossible. As for a "well flagged" code being faster, let me assure you that that's not necessarily the case. Locks have quite a bit of overhead, even when you run with a single thread.
It's better to partition the dataset (if possible).
Now your compiler attributes priorities to each threaded process. Those priority permutations are the 'genes' that get evolved. Higher priority here, lower there... Possibly also the flag positions (within the determined, logicaly safe, race free boundries). Make sense? Not really. It's clear to me you've not really tried your ideas out, even in minature. If I'm wrong, prove it by example. I rather like being proved wrong that way!
It can be achieved (in particular cases). It can even sometimes be surpassed [...] Theoretically, the limit shouldn't be surpassable (and very hard to actually reach). I was with you until that, what do you mean? He means that the limit should be impossible to better, and definitely is very difficult to reach with real code anyway. (AIUI, you have to perform problem-specific tuning, but that's hardly ever worth it; few people have problems where that level of developer effort is justified by the resulting time saving, as it's usually cheaper and just to just let the program run a bit longer.)
So let me get this right... you're leaving your laptop on your desk powered on every night. Why do you have a laptop? If you're doing a business trip every few weeks, it's really good to be able to take your computer with you. (I don't know about you, but I'm really paranoid about computers I don't maintain; you never know what scum have been using it before you.) But there's no need to take the thing with you at all times; remote access technologies work well (and anyway, it's irritating to have to lose the state of your ssh sessions...)
In ten years, efficient programming won't be difficult, it will be impossible unless we evolve our engeneering concepts dramatically to adapt to this paradigm shift (sorry for the cliche phrase but its apt). I think I agree with this. I think that the key to this is going to be to go to an architecture based far more on message passing rather than shared memory (why? because we have really good evidence that it scales, and there's far less hair-loss involved when things go wrong; shared-memory parallelism is infamous for schrödingbugs and heisenbugs). The other advantage with doing this is that extending the program to work across more than one computer is far easier too.
I believe the only way, will be to use genetic algorithms (suited to multiprocessors them selves) to adaptively compile code. Effectively evolving it until its optimized. I take it that this is using a genetic algorithm as a magic wand? And that you won't mind if upgrading the computer (or even just plugging in new hardware) breaks everything totally? GAs frequently tend to lead to solutions that have very odd timing behaviour indeed...
Fine-grained parallelism works fine. It works in your NVidia, SIMD-based graphics coprocessor, does it not? Locking and syncing is a problem only in a non-deterministic environment like multithreading. Fine-grained parallelism is temporally deterministic because the temporal (concurrent or sequential) order of code execution can be precisely determined. It really really depends on the problem and the algorithm. Some things are easy to parallelize, especially if they don't need (much) shared writable memory, but others are furiously hard.
you'll probably have to wire the registers between cores directly into each other in order to avoid the enormous overhead of an external chip.
Not really. There is a way to design a multicore processor such that only neighboring cores cooperate on related computation. It is part of the self-balancing mechanism. I can't go into detail but suffice it to say that if you keep your inter-core communication performance penalty at a fixed level regardless of the number of cores, you have a winner. As I said above, it really depends on what you're doing. Some classes of problems just don't and can't have nice communication patterns, and if you've got one where you've got these inherent non-local effects, no amount of cleverness is going to let you avoid the hard fact that communication costs will dominate them. Other problems are much more tractable though; it's definitely not all doom and gloom. Just don't sound off and claim that it's all solved (nope!) or that some simple hardware-level cleverness will save us (nope again!) but instead study what's really known so that you can sound more knowledgeable. A good place to start reading up is with the thirteen dwarfs paper (PDF).
"c:\documents and settings\username" is what you want (commonly called the "profile"). Of course, you can change the location where profiles are stored -- I just gave the default. Also, the name of the default profile location varies by locale.
I think we are really getting philosophical here, but there is no controller. You (the office document) fetch the data from the DB. So, office document = view and DB = model. There is no controller. The definition of controller I have is: "Processes and responds to events, typically user actions, and may invoke changes on the model." - The office document does not do that. It only displays the data. I disagree. There's a Controller. It's the trivial default one implemented by the viewing application. (Of course, it only really gets interesting when you start pushing changes in the document back at the database; that's when you start to build a controller of substance...)
Re:really, i didn't make it up
on
Matter
·
· Score: 1
And, yes, there is digging required: Inversions and Look to Windward are, for example, not available on amazon (Look to Windward is "temporarily out of stock", and Inversions appears to be out of print and only available used.) So order over the internet from Amazon's UK site, who seem to have plenty of copies, findable in seconds. (Yes, Martha! You can transport SF books over international borders by post!) It costs a bit more and takes a bit longer, but I've only ever had good experiences with ordering books from overseas Amazon sites.
why not put the whole thing in the basement and use a thin client? Because thin clients suck, and have done for decades? A thick client (such as most people use) that puts the GUI locally works better almost all of the time.
You don't want to start arguing with your PocketPC about traffic and directions: No, I said Springfield, not Slingblade! *crash* It could be worse, much much worse: No, I said goats, not goatse! My eyes!
This story and others like it are part of a move by publishers and the traditional media to undermine a phenomena that they are terrified of because it makes them less relevant to many people. While Wikipedia is imperfect it is still no worse that the traditional media, which has always been vulnerable to corrupt editorial manipulation, marketing scams and shoddy journalism. Also, traditional media has a real tendency to ignore stuff that doesn't match their prejudices and which isn't the Next Big Thing.
Slashdot Mirror
Can we collect the DNA of the current Administration preemptively? It'd save a lot of time later on, and we already know they'll qualify for membership of the DB...
To cut a long story short, don't take part in a pissing contest with the floating point guys. They'll win.
Sometimes the jackboots of fascistic pain are the only sane administration strategy.
Of course, I can also remember when getting anything (e.g. the Mosaic manual) over the Atlantic was an exercise in frustration too due to the shortage of bandwidth. Bandwidth boosts were the things that saved the internet, back then in '93.
I'll tell you, those things may help you learn your language or platform better but it will not help you be a better engineer. Unfortunately only time in the trenches does that. In my experience, you want both exposure to open source (so you can learn good habits) and time in the trenches (so you can see what's important). If you're lucky, you can combine those two things in the same job. Most people aren't that lucky; be prepared to put time in on OSS at the weekend. (If you like coding for fun, that's no big deal!)
If you (as a nation) want it done, stop finding stupid excuses (and mendacious "regulators") and just fscking do it!
RS-232! Another port killed by (the frankly much better) USB, it had the interesting feature of coming in two widths of connector. The only uses for it I ever had were for connecting my (ultra-fast at the time) 14,400 baud modem, and for programming the Mindstorms brick. (That went to USB with v2, but v1 and 1.5 used RS-232.)
It's better to partition the dataset (if possible). Now your compiler attributes priorities to each threaded process. Those priority permutations are the 'genes' that get evolved. Higher priority here, lower there... Possibly also the flag positions (within the determined, logicaly safe, race free boundries). Make sense? Not really. It's clear to me you've not really tried your ideas out, even in minature. If I'm wrong, prove it by example. I rather like being proved wrong that way!
Not really. There is a way to design a multicore processor such that only neighboring cores cooperate on related computation. It is part of the self-balancing mechanism. I can't go into detail but suffice it to say that if you keep your inter-core communication performance penalty at a fixed level regardless of the number of cores, you have a winner. As I said above, it really depends on what you're doing. Some classes of problems just don't and can't have nice communication patterns, and if you've got one where you've got these inherent non-local effects, no amount of cleverness is going to let you avoid the hard fact that communication costs will dominate them. Other problems are much more tractable though; it's definitely not all doom and gloom. Just don't sound off and claim that it's all solved (nope!) or that some simple hardware-level cleverness will save us (nope again!) but instead study what's really known so that you can sound more knowledgeable. A good place to start reading up is with the thirteen dwarfs paper (PDF).