FWIW, some variant of this, but using a single memory (flash, HDD, etc.) solution is how many competently written firmware update strategies work. This helps the end user by making sure that field updates are robust, and helps the development staff by ensuring they won't irretrievably bork a dev board during one of the *many* reflashes that takes place during the software dev cycle.
In other cases, the only thing that's inviolate is the actual early-stage flash loader. At boot time, it verifies the firmware image then performs a handoff to it. It also has a hook (e.g. a switch, magic keys, etc.) that puts it into firmware loading mode -- always available even if the main f/w image is corrupted. This is probably the best way to handle the situation. Use a ROM with two logical entities: a first-stage loader/flasher and a complete BIOS image, accompanied by a flash chip for the most current BIOS. The first-stage always allows the user to override at boot to the non-overwritable "safe" BIOS, from which a new most-current version can be reflashed should anything bad happen. Note: all NVRAM would have to be ignored in this "safe mode" for security reasons...
If a web server starts sending back unexpected garbage replies to a web browser, we would all expect the web browser to handle such replies without problem. The same should hold true for RSS readers.
Learn this, and learn it well, or else STFU and get out of the software industry: the liberal in what you accept/strict in what you output principle only really applies for certain circumstances, such as interacting with a human user. People are a bit "fuzzy" from a software perspective, so a wise degree of liberal acceptance is good. For example, a form that accepts a phone number should be able to accept "(222)555-1212" or "222-555-1212" or "2225551212" or a mess of similar variations... it should then normalize that data and present it back to the user in a single (i.e. strict) conventional form as appropriate.
However, being liberal in what you accept in the context of heterogeneous agents interoperating is moronic. Why? Another poster put it wonderfully as software development becoming an "arms race". If you can't get your software to output the common lingo, you don't get to play. The rest of us don't have time to code around your incompetence. As time goes on, a strict acceptance policy forces the burden onto the content providers, not the clients. Why is this better? Because it is becomes far simpler to validate correct client behavior. I'd also argue that it's far easier to get the content provider to produce valid output. This is partly because creating tools to support adherence to a standard is *much* simpler than figuring out all the whacky variations of liberal acceptance that are valid for complex document formats. Validators, app frameworks, GUI tools, skilled devs, etc., etc. all of these things can be brought to bear on the problem of creating correct output.
Looks as if they are cutting costs. The early versions look much more refined and "professional".
The interior design and layout of a computer mainboard is not driven by superficial aesthetics, but by a host of pragmatic issues. These issues include airflow and heat dissipation management, crosstalk issues between various components and/or traces on the board (ever had a laptop where you could hear the hard drive in the audio out?), placement of offboard connectors, access for upgrades, and so forth. Hardware manufacturers shouldn't be wasting time trying to lump the requirement of "pretty, pretty" on a concealed part! Some board designs do turn out to have a certain visual appeal, but I certainly wouldn't want that at the cost of any of the practical concerns, or at an increased system cost.
WMP sucks anyways. It's a crappy video player for anything more sophisticated that hitting "play" and letting the video go from start to end unperturbed. Playback control gripes include:
WMP (for Mac or Windows) cannot frame-step.
Dragging the point of play (or FFW/FRW) causes a lag of up to many seconds where the audio is playing at the new point of playback, but the video hasn't caught up yet. Seems to be that the player just lets the codec twiddle its thumbs until the next fully encoded-frame (as opposed to relative encoded frame) happens along.
FWIW, QuickTime player handles these cases for its formats quite well, and VirtuaDub on Windows can play WMVs without these issues as well.
Hmm... looks like one of my pet peeves hasn't been addressed in 1.5: Thunderbird's handling of "Plain Text" sucks rocks. E.g. Start composing a new message, then select Options->Format->Plain Text Only.
Now copy some text from a non-plain text email or other source, then paste or paste-as-quotation into the new message window. Does it come out as plain text? NO. Even in plain text mode, you still have to use the (no-quick-key-binding) Edit->Paste Without Formatting. sheesh.
Similarly, edit a message in a non-plain-text form (e.g. with a proportional font selected), then switch the message to plain text -- all TB does it to hide the formatting toolbar... no actual format change takes place. WTF? Is TB lying about having switched to plain text formatting... or will the message silently be reformatted to plain text when sent? If the latter, what ever happened to WYSIWYG?
And yes, I've dug into bugzilla, found the relevant bugs, voted for them, etc.
FYI, that's a larger form-factor ExpressCard/54 card, as are all of the FW800 cards that I dug up from a (very hasty) Google search. The/54 cards won't fit in the MacBook Pro's/34 slot; it's too wide (though the contact/electrical interface is the same). But it seems a no-brainer to expect that someone will start selling a FW800 ExpressCard/34 on the heels of the MacBook Pro announcement.
What about the memory controller, are they adding the power consumption of that to the CPU - to be properly compared to the integrated system that AMD X2 uses ?.
Parent and moderators, RTFA. The power comparisons in the original article are for total system power consumption. Quote:
In fact, a 2.0GHz Yonah under 100% load consumes less power than an Athlon 64 X2 3800+ at idle.
Note that these figures are for desktop systems using these chips. Properly engineered laptops using these chips will have lower values still.
A website doesn't really have much business selecting particular named fonts, content versus presentation and all that. If you use CSS then you can quite reasonably limit yourself to normal, sans-serif and monospaced [...]
Sure, that "Slashdot" in the upper-left corner would look great in 8pt Courier.:-P FYI, most if not all modern broswers let users force font settings and/or employ a user-specified CSS file. Users already have the choice.
If you want to bitch about bad designs (or celebrate good ones) on the web (or in print) then join the crowd. But the idea that CSS means the end of presentation on the web, as you imply, is inane. CSS specifies the separation of content and presentation, not the reduction of either. As Eric Meyer, the CSS Zen Garden, and others have shown, CSS+(X)HTML seriously improves the ability to maintain and enhance both content and presentation versus old-style HTML-font-tag-and-attribute-soup.
While content-based web pages need to be accessible (which sIFR achieves, FWIW), the idea that the web is the end of typography in design is also inane. Web typography does suck right now, but mostly because designers need to employ techniques such as image overlays and sIFR to do anything remotely interesting.
Some of you here may remember the Vivarin Lyrics Server, the story of which is told here.
Some of the details of Vivarin's story are *very* interesting. The overall arc is similar to pearLyrics: a new search tool for lyrics is created, then eventually cease-and-desisted. But many of the details, and the early internet era in which they occured, make for a good read.
It's sad, even pathetic, that in all these years the RIAA and its member companies haven't gotten even the least bit of clue. These sorts of search services add enourmous value. Thousands of people were able to identify and purchase music based on Vivarin's services ("what is that song, I remember a few words..?"). Heck, Warner's laywers called to provide thanks as Vivarin had helped them to win a legal case.
I seriously hope that the RIAA's stranglehold doesn't let up before they realize that hold is around their collective neck.
But perhpas this is what (F)OSS software will get for us, an army of coders coupled to an army of blade vendors, with dumb devices at the edge.
I disagree with the "dumb devices" bit; that's too cynical. We can have devices at the edge that are only as smart as they need to be. This enables tons of networked apps that can relay dynamic information: news, airline flight status, and so forth. Increasingly, these tools are built into clients that aren't even web browsers (e.g. RSS readers, OS X dashboard widgets, cellphones, etc.). These networked apps make devices at the edge smarter (=== more useful), often in ways that a smarter (== more powerful) device couldn't possibly emulate.
Put another way, I could have a Cray in my basement -- but that still wouldn't help me conveniently find out when my friend's flight's arriving. The army of coders and blade vendors are still necessary to enable that application, despite a Really Smart Device providing heat for my house... ^_^
Have you *ever* written/debugged a multi-threaded program?
Yep. I've done this type of work and it's possible for it to not be a big deal -- provided that the developers stick to a robust set of patterns and protocols for interacting with the DSP compute hardware. For sanity's sake, all of the sync code should be wrapped up into frameworks so that various sub-teams never end up wandering off and generating buggy one-off low-level synchronization code. Devs coding for the specialized hardware (DSP/Cell) write to interfaces that are clean and purely single-threaded. Clients on the main hardware threads never need to screw around with low-level sync code. The framework itself can be instrumented to assist in finding and debugging any odd concurrency issues that come up, but for the most part a well-designed framework allieviates a lot of annoying concurrency bugs in the first place. When bugs are found they get quashed once and for-all in the framework, instead of being distributed willy-nilly (and sometimes in non-obvious ways) around the system.
To folks looking for further reading, I suggest starting with Pattern Oriented Software Architecture, Vol 2: Patterns for Concurrent and Networked Objects by Douglas Schmidt, et. al. A number of these patterns are also available as papers from Schmidt's website -- see Google. I also recommend checking out the Future(s) pattern, not covered in POSA2. The idea is to have an asynchronous operation return a Future object that represents the result of the async computation. When the result in needed, the object either returns it (if the async computation is done) or blocks (if the async computation isn't done). This allows both batching of multiple parallel async activities, as well as result/input dependency management. A somewhat simple example:
Future<Texture> t = LoadTexture(textureid); Future<Model> m = LoadModel(modelid);
Future<Model> munged_m = Transform(m.result()/* may wait*/,
transform_params);
The nice thing is that the work requests (here, loading or transforming data) can (potentially) all run in parallel. Note that LoadTexture, LoadModel, and Transform all return instantly -- we'll only wait for a result when it's called for, and we only wait if the result is not already available.
They are going to spend a LOT of money to avoid the unavoidable...
Actually, they don't have to spend that much money. They just need to make it robust enough that it can't be casually broken. Then the DMCA does the rest. The hackers can do their worst, but whether or not they succeed won't matter.
Apple wins either way because the prime objective is to prevent en-masse adoption of Mac OS X on generic Intel hardware, greatly eroding Apple's own hardware sales. As long as Apple's hardware sales are safe, a modest number of hacked installations serves a positive purpose -- hacked copies are just try-before-you-buy by encouraging folks to make their next computer purchase from Apple.
The only reason that Linux would become a hobby is if you felt a need to update things that don't need updating continually.
Err.. or until you suddenly have problems getting two sounds to play at once, or with some other equally banal day-to-day usage scenario.
Or more simply than that, you need tools to do your work which are either not sufficiently mature or outright don't exist yet on Linux. Also known as: "It's about the apps."
In all fairness, this isn't the *nix distributions that are at fault: it's the upstream software developers. Aside from a few valiant distro package maintainers, all docs seem to come from upstream these days. I totally agree that info pages used to suck rocks, mostly because they seemed to be an excuse for really sparse documentation encased in really bad hypertext. Fortunately, the quality of the documentation (and the hypertext organization) has improved considerably over the years...
No, it doesn't. This is currently provided by the Lunar Eclipse project, which publishes a few Eclipse plugins. Specifically, look at the rectangle copy/cut/paste/edit operations in the Editor Enhancements plugin created by that project. (Note: the Emacs-style Alt-/ completion mentioned on these pages was integrated as a part of Eclipse itself.)
Also, Eclipse has a useful stock feature which covers one use case for rectangular edits: block indent change. Highlight a few lines of text, then hit tab/S-tab to increase/decrease the indent of all highlighted lines uniformly. It's such a simple feature, but I love it.
Directors and producers need to be more demanding of their digital special effects. They should reject mediocre work as readily as wire work with, well, visible wires.
s/digital special effects/story and script quality/
Eye-candy is nice, but there have been so many awful films/shows created with great FX... and so many great stories that succeeded despite cheap FX that I really have to disagree here. I'd greatly prefer to have better stories and scripts than better effects. As an example of the former case, consider the Final Fantasy Movie. The realism of the rendering was really ground-breaking at the time; it was just plain gorgeous. But the movie was hobbled by plain lousy writing.
Perhaps the archetypical example of the other side is Doctor Who -- lots of great stories by great authors in that show's history... and the notorious BBC low-budget special effects. Effects which many fans came to enjoy _because_ the show was enjoyable without hinging on eye-candy.
Mankind's future in computing must build on immoveable foundations of theory and logic if it is to progress into a realm where machines of IQs in the millions work at our behest.
What a complete pipe dream. This sort of mathematics fetish embodies one of the same failings that causes so much pain in modern software development. You refer to "the metaphorical bridges of computer science still [...] falling down", yet you talk like a mathematician not a civil engineer. In my opinion, you've lost either way, because you ignore the real-world problem domain in favor of a Magical Solution.
Michael Jackson (the software development author, not the pop star) put it well in this book, p. 188: "Some chemists and biologists suffer from 'physics envy'. They wish their own subjects had the character and repuatation and achievements of physics. In the same way, a lot of software scientists suffer from 'engineering envy'." In the same way, you're getting into a wierd mathematics/engineering envy. Jackson goes on to say:
The most prominent difference [between software development and traditional engineering] is that the traditional, established branches of engineering are all highly specialized. Chemical engineers don't build electricity generating plants. The automobile engineers at GM or Toyota would not accept a commission to specify a replacement for the Brooklyn Bridge. [...] In fact, the established disciplines are so specialized and so different as to have almost nothing in common. [...] Software engineers would be analogous to 'physical engineers', imaginary polymaths who understand any material, to serve any purpose.
Moreover, you assume that "progressing" into a "realm where machines of IQs in the millions work at our behest" is even a remotely desirable goal. This sounds more like a sci-fi wet dream than a desirable end. The real problems that large-scale software development faces today are not machine problems, but human problems. Questions such as "how do we get a team of developers to efficiently develop software to meet a goal?" and "what _is_ the goal, and how do we tell if the software meets it?" are vastly important, and completely unaddressed by formal methods of the "immoveable foundations of theory and logic" variety. You've got a solution looking for a problem.
This is not to say that formalisms (or specs...;-) are useless; far from it. Computer science itself is the ugly-duckling melding where mathematics and engineering meet... and some of the most promising modern developments in programming languages and operating systems research have gorgeous (yet practical!) formally based foundations. Yet the successes here are all heavily grounded in real-world problem domains. Formalisms and mathematics here are modelling tools used by folks intimately familiar with these messly, real-world problems.
And to circle back to the thread's topic: specs are downright harmful when divorced from reality, or when treated as a rigid and immutable gospel. OTOH, specs that are deeply rooted in the reality of the real-world problem domain, and which evolve to encompass the knowledge gained through the development process, can be powerful tools for communication about a software project and its goals.
But such fine-grained controls are incredibly tedious
Hogwash. The grsecurity patches to the Linux kernel provide one approach to fine-grained access control that greatly eases the tedium of managing fine-grained rulesets. In short, grsecurity's approach is based on automatic learning -- let the system run in a permissive mode doing the things it's supposed to do, then generate a ruleset based on that activity. The system then runs with the generated permissions ruleset. The admin may need to tweak the ruleset for various reasons, but the tools provide a huge leg-up over any manual attempt to lock down a system that wasn't designed for it. And there's the rub... design.
With an OS that provides robust fine-grained access control, new software patterns and system tools emerge to manage the complexity. We didn't go from teletypes to OpenGL in one leap... For example, what if the only entity in the system that could even know the password database existed, much less access it, was the password service? Shadow passwords pale compared to that kind of isolation. What if the default permissions for an application effectively sandbox that app in a jail that makes Java in a chroot look like a toy? You'd then have to build additional infrastructure to allow the apps (and thus the user) do their work.
It's all quite possible, and folks are working on it now. This is the shift in mindset from allow-all by default to allow-nothing by default, and the work necessary to make that approach practical at the level of an OS. Take a look at http://www.coyotos.org/ and its predecessor http://www.eros-os.org/ for examples of current work on a OS (kernel and support infrastructure) designed for security (and performance) from base principles.
It's a daunting task, but damn well worth the effort IMO.
FWIW, it's also trivial to do the same thing under Eclipse using PyDev. Mark a block of text, then hit tab or shift-tab to indent/unindent. If you're an Emacs user, turn on Eclipse's built-in Emacs keybinding set and it's home away from home...
While I agree that transparently encrypted folders are a no-brainer feature wise, there is an option available today that works pretty well under Mac OS X. Create a sparse encrypted disk image. If you desire added transparency, then add the image's password to your Keychain -- then you can open the encrypted image just like any other.dmg file while you're logged in.
Re:Proof that first to market doesn't equal succes
on
Rio Brand Closes Doors
·
· Score: 1
if you can get there first, you'll get mindshare
What I recall from examples I've read (hmm.. from Don Norman's The Invisible Computer?), was that all of the prime examples of first mover's advantage were from stable, commoditized markets. But strategic marketing, or strategy of any kind, seemed rather irrelevant to much of the 90's VC-money-powered mindset.
IBM is cool now because they're actively 1) paying for linux advertising (related to IBM, but still), 2) writing lots of Linux articles, 3) contributing to linux, etc etc.
Not just Linux, mind! Let's not forget the Eclipse IDE, and a laundry list of various other smaller open source projects that IBM has released and/or sponsored.
While I'm at it, I'll plug a project that's recently made my life more pleasant: Aleks Totic's and Fabio Zadrozny's great work on PyDev, for Eclipse. From that site: "PyDev is a plugin that enables users to use Eclipse for Python development. It comes with many goodies such as code completion, syntax highlighting, syntax analysis, refactor, debug and many others."
Slashdot Mirror
[Description of multi-chip BIOS update system]
FWIW, some variant of this, but using a single memory (flash, HDD, etc.) solution is how many competently written firmware update strategies work. This helps the end user by making sure that field updates are robust, and helps the development staff by ensuring they won't irretrievably bork a dev board during one of the *many* reflashes that takes place during the software dev cycle.
In other cases, the only thing that's inviolate is the actual early-stage flash loader. At boot time, it verifies the firmware image then performs a handoff to it. It also has a hook (e.g. a switch, magic keys, etc.) that puts it into firmware loading mode -- always available even if the main f/w image is corrupted. This is probably the best way to handle the situation. Use a ROM with two logical entities: a first-stage loader/flasher and a complete BIOS image, accompanied by a flash chip for the most current BIOS. The first-stage always allows the user to override at boot to the non-overwritable "safe" BIOS, from which a new most-current version can be reflashed should anything bad happen. Note: all NVRAM would have to be ignored in this "safe mode" for security reasons...
If a web server starts sending back unexpected garbage replies to a web browser, we would all expect the web browser to handle such replies without problem. The same should hold true for RSS readers.
Learn this, and learn it well, or else STFU and get out of the software industry: the liberal in what you accept/strict in what you output principle only really applies for certain circumstances, such as interacting with a human user. People are a bit "fuzzy" from a software perspective, so a wise degree of liberal acceptance is good. For example, a form that accepts a phone number should be able to accept "(222)555-1212" or "222-555-1212" or "2225551212" or a mess of similar variations... it should then normalize that data and present it back to the user in a single (i.e. strict) conventional form as appropriate.
However, being liberal in what you accept in the context of heterogeneous agents interoperating is moronic. Why? Another poster put it wonderfully as software development becoming an "arms race". If you can't get your software to output the common lingo, you don't get to play. The rest of us don't have time to code around your incompetence. As time goes on, a strict acceptance policy forces the burden onto the content providers, not the clients. Why is this better? Because it is becomes far simpler to validate correct client behavior. I'd also argue that it's far easier to get the content provider to produce valid output. This is partly because creating tools to support adherence to a standard is *much* simpler than figuring out all the whacky variations of liberal acceptance that are valid for complex document formats. Validators, app frameworks, GUI tools, skilled devs, etc., etc. all of these things can be brought to bear on the problem of creating correct output.
Looks as if they are cutting costs. The early versions look much more refined and "professional".
The interior design and layout of a computer mainboard is not driven by superficial aesthetics, but by a host of pragmatic issues. These issues include airflow and heat dissipation management, crosstalk issues between various components and/or traces on the board (ever had a laptop where you could hear the hard drive in the audio out?), placement of offboard connectors, access for upgrades, and so forth. Hardware manufacturers shouldn't be wasting time trying to lump the requirement of "pretty, pretty" on a concealed part! Some board designs do turn out to have a certain visual appeal, but I certainly wouldn't want that at the cost of any of the practical concerns, or at an increased system cost.
FWIW, QuickTime player handles these cases for its formats quite well, and VirtuaDub on Windows can play WMVs without these issues as well.
Hmm... looks like one of my pet peeves hasn't been addressed in 1.5: Thunderbird's handling of "Plain Text" sucks rocks. E.g. Start composing a new message, then select Options->Format->Plain Text Only.
Now copy some text from a non-plain text email or other source, then paste or paste-as-quotation into the new message window. Does it come out as plain text? NO. Even in plain text mode, you still have to use the (no-quick-key-binding) Edit->Paste Without Formatting. sheesh.
Similarly, edit a message in a non-plain-text form (e.g. with a proportional font selected), then switch the message to plain text -- all TB does it to hide the formatting toolbar... no actual format change takes place. WTF? Is TB lying about having switched to plain text formatting... or will the message silently be reformatted to plain text when sent? If the latter, what ever happened to WYSIWYG?
And yes, I've dug into bugzilla, found the relevant bugs, voted for them, etc.
FYI, that's a larger form-factor ExpressCard/54 card, as are all of the FW800 cards that I dug up from a (very hasty) Google search. The /54 cards won't fit in the MacBook Pro's /34 slot; it's too wide (though the contact/electrical interface is the same). But it seems a no-brainer to expect that someone will start selling a FW800 ExpressCard/34 on the heels of the MacBook Pro announcement.
Parent and moderators, RTFA. The power comparisons in the original article are for total system power consumption. Quote:
Note that these figures are for desktop systems using these chips. Properly engineered laptops using these chips will have lower values still.
For folks working with Rails, it's worth looking at RadRails, available as a standalone IDE (built on the Eclipse RCP), or as an Eclipse plugin.
A website doesn't really have much business selecting particular named fonts, content versus presentation and all that. If you use CSS then you can quite reasonably limit yourself to normal, sans-serif and monospaced [...]
:-P FYI, most if not all modern broswers let users force font settings and/or employ a user-specified CSS file. Users already have the choice.
Sure, that "Slashdot" in the upper-left corner would look great in 8pt Courier.
If you want to bitch about bad designs (or celebrate good ones) on the web (or in print) then join the crowd. But the idea that CSS means the end of presentation on the web, as you imply, is inane. CSS specifies the separation of content and presentation, not the reduction of either. As Eric Meyer, the CSS Zen Garden, and others have shown, CSS+(X)HTML seriously improves the ability to maintain and enhance both content and presentation versus old-style HTML-font-tag-and-attribute-soup.
While content-based web pages need to be accessible (which sIFR achieves, FWIW), the idea that the web is the end of typography in design is also inane. Web typography does suck right now, but mostly because designers need to employ techniques such as image overlays and sIFR to do anything remotely interesting.
Some of you here may remember the Vivarin Lyrics Server, the story of which is told here.
Some of the details of Vivarin's story are *very* interesting. The overall arc is similar to pearLyrics: a new search tool for lyrics is created, then eventually cease-and-desisted. But many of the details, and the early internet era in which they occured, make for a good read.
It's sad, even pathetic, that in all these years the RIAA and its member companies haven't gotten even the least bit of clue. These sorts of search services add enourmous value. Thousands of people were able to identify and purchase music based on Vivarin's services ("what is that song, I remember a few words..?"). Heck, Warner's laywers called to provide thanks as Vivarin had helped them to win a legal case.
I seriously hope that the RIAA's stranglehold doesn't let up before they realize that hold is around their collective neck.
But perhpas this is what (F)OSS software will get for us, an army of coders coupled to an army of blade vendors, with dumb devices at the edge.
I disagree with the "dumb devices" bit; that's too cynical. We can have devices at the edge that are only as smart as they need to be. This enables tons of networked apps that can relay dynamic information: news, airline flight status, and so forth. Increasingly, these tools are built into clients that aren't even web browsers (e.g. RSS readers, OS X dashboard widgets, cellphones, etc.). These networked apps make devices at the edge smarter (=== more useful), often in ways that a smarter (== more powerful) device couldn't possibly emulate.
Put another way, I could have a Cray in my basement -- but that still wouldn't help me conveniently find out when my friend's flight's arriving. The army of coders and blade vendors are still necessary to enable that application, despite a Really Smart Device providing heat for my house... ^_^
Yep. I've done this type of work and it's possible for it to not be a big deal -- provided that the developers stick to a robust set of patterns and protocols for interacting with the DSP compute hardware. For sanity's sake, all of the sync code should be wrapped up into frameworks so that various sub-teams never end up wandering off and generating buggy one-off low-level synchronization code. Devs coding for the specialized hardware (DSP/Cell) write to interfaces that are clean and purely single-threaded. Clients on the main hardware threads never need to screw around with low-level sync code. The framework itself can be instrumented to assist in finding and debugging any odd concurrency issues that come up, but for the most part a well-designed framework allieviates a lot of annoying concurrency bugs in the first place. When bugs are found they get quashed once and for-all in the framework, instead of being distributed willy-nilly (and sometimes in non-obvious ways) around the system.
To folks looking for further reading, I suggest starting with Pattern Oriented Software Architecture, Vol 2: Patterns for Concurrent and Networked Objects by Douglas Schmidt, et. al. A number of these patterns are also available as papers from Schmidt's website -- see Google. I also recommend checking out the Future(s) pattern, not covered in POSA2. The idea is to have an asynchronous operation return a Future object that represents the result of the async computation. When the result in needed, the object either returns it (if the async computation is done) or blocks (if the async computation isn't done). This allows both batching of multiple parallel async activities, as well as result/input dependency management. A somewhat simple example:The nice thing is that the work requests (here, loading or transforming data) can (potentially) all run in parallel. Note that LoadTexture, LoadModel, and Transform all return instantly -- we'll only wait for a result when it's called for, and we only wait if the result is not already available.
They are going to spend a LOT of money to avoid the unavoidable...
Actually, they don't have to spend that much money. They just need to make it robust enough that it can't be casually broken. Then the DMCA does the rest. The hackers can do their worst, but whether or not they succeed won't matter.
Apple wins either way because the prime objective is to prevent en-masse adoption of Mac OS X on generic Intel hardware, greatly eroding Apple's own hardware sales. As long as Apple's hardware sales are safe, a modest number of hacked installations serves a positive purpose -- hacked copies are just try-before-you-buy by encouraging folks to make their next computer purchase from Apple.
The only reason that Linux would become a hobby is if you felt a need to update things that don't need updating continually.
Err.. or until you suddenly have problems getting two sounds to play at once, or with some other equally banal day-to-day usage scenario.
Or more simply than that, you need tools to do your work which are either not sufficiently mature or outright don't exist yet on Linux. Also known as: "It's about the apps."
In all fairness, this isn't the *nix distributions that are at fault: it's the upstream software developers. Aside from a few valiant distro package maintainers, all docs seem to come from upstream these days. I totally agree that info pages used to suck rocks, mostly because they seemed to be an excuse for really sparse documentation encased in really bad hypertext. Fortunately, the quality of the documentation (and the hypertext organization) has improved considerably over the years...
[Eclipse lacks] block / column mode cut/copy/paste support..
No, it doesn't. This is currently provided by the Lunar Eclipse project, which publishes a few Eclipse plugins. Specifically, look at the rectangle copy/cut/paste/edit operations in the Editor Enhancements plugin created by that project. (Note: the Emacs-style Alt-/ completion mentioned on these pages was integrated as a part of Eclipse itself.)
Also, Eclipse has a useful stock feature which covers one use case for rectangular edits: block indent change. Highlight a few lines of text, then hit tab/S-tab to increase/decrease the indent of all highlighted lines uniformly. It's such a simple feature, but I love it.
Directors and producers need to be more demanding of their digital special effects. They should reject mediocre work as readily as wire work with, well, visible wires.
s/digital special effects/story and script quality/
Eye-candy is nice, but there have been so many awful films/shows created with great FX... and so many great stories that succeeded despite cheap FX that I really have to disagree here. I'd greatly prefer to have better stories and scripts than better effects. As an example of the former case, consider the Final Fantasy Movie. The realism of the rendering was really ground-breaking at the time; it was just plain gorgeous. But the movie was hobbled by plain lousy writing.
Perhaps the archetypical example of the other side is Doctor Who -- lots of great stories by great authors in that show's history... and the notorious BBC low-budget special effects. Effects which many fans came to enjoy _because_ the show was enjoyable without hinging on eye-candy.
What a complete pipe dream. This sort of mathematics fetish embodies one of the same failings that causes so much pain in modern software development. You refer to "the metaphorical bridges of computer science still [...] falling down", yet you talk like a mathematician not a civil engineer. In my opinion, you've lost either way, because you ignore the real-world problem domain in favor of a Magical Solution.
Michael Jackson (the software development author, not the pop star) put it well in this book, p. 188:
"Some chemists and biologists suffer from 'physics envy'. They wish their own subjects had the character and repuatation and achievements of physics. In the same way, a lot of software scientists suffer from 'engineering envy'." In the same way, you're getting into a wierd mathematics/engineering envy. Jackson goes on to say:
Moreover, you assume that "progressing" into a "realm where machines of IQs in the millions work at our behest" is even a remotely desirable goal. This sounds more like a sci-fi wet dream than a desirable end. The real problems that large-scale software development faces today are not machine problems, but human problems. Questions such as "how do we get a team of developers to efficiently develop software to meet a goal?" and "what _is_ the goal, and how do we tell if the software meets it?" are vastly important, and completely unaddressed by formal methods of the "immoveable foundations of theory and logic" variety. You've got a solution looking for a problem.
This is not to say that formalisms (or specs...
And to circle back to the thread's topic: specs are downright harmful when divorced from reality, or when treated as a rigid and immutable gospel. OTOH, specs that are deeply rooted in the reality of the real-world problem domain, and which evolve to encompass the knowledge gained through the development process, can be powerful tools for communication about a software project and its goals.
But such fine-grained controls are incredibly tedious
Hogwash. The grsecurity patches to the Linux kernel provide one approach to fine-grained access control that greatly eases the tedium of managing fine-grained rulesets. In short, grsecurity's approach is based on automatic learning -- let the system run in a permissive mode doing the things it's supposed to do, then generate a ruleset based on that activity. The system then runs with the generated permissions ruleset. The admin may need to tweak the ruleset for various reasons, but the tools provide a huge leg-up over any manual attempt to lock down a system that wasn't designed for it. And there's the rub... design.
With an OS that provides robust fine-grained access control, new software patterns and system tools emerge to manage the complexity. We didn't go from teletypes to OpenGL in one leap... For example, what if the only entity in the system that could even know the password database existed, much less access it, was the password service? Shadow passwords pale compared to that kind of isolation. What if the default permissions for an application effectively sandbox that app in a jail that makes Java in a chroot look like a toy? You'd then have to build additional infrastructure to allow the apps (and thus the user) do their work.
It's all quite possible, and folks are working on it now. This is the shift in mindset from allow-all by default to allow-nothing by default, and the work necessary to make that approach practical at the level of an OS. Take a look at http://www.coyotos.org/ and its predecessor http://www.eros-os.org/ for examples of current work on a OS (kernel and support infrastructure) designed for security (and performance) from base principles.
It's a daunting task, but damn well worth the effort IMO.
Given the topic, I'm amused that your sig is simultaneously on topic and out of date:
Keep firefox secure, vote for bug #262536
Bug 262536 "Bigger notice for updates and critical updates" has been marked resolved by Ben Goodger: "This is fixed by the new update system UI."
8-)
FWIW, it's also trivial to do the same thing under Eclipse using PyDev. Mark a block of text, then hit tab or shift-tab to indent/unindent. If you're an Emacs user, turn on Eclipse's built-in Emacs keybinding set and it's home away from home...
you are going to be swinging a 'bat'. throwing a 'ball'. playing golf, etc etc etc.
Which *really* makes me hope that they ship the production version with a racquetball-style wrist tether! %-)
While I agree that transparently encrypted folders are a no-brainer feature wise, there is an option available today that works pretty well under Mac OS X. Create a sparse encrypted disk image. If you desire added transparency, then add the image's password to your Keychain -- then you can open the encrypted image just like any other .dmg file while you're logged in.
if you can get there first, you'll get mindshare
What I recall from examples I've read (hmm.. from Don Norman's The Invisible Computer?), was that all of the prime examples of first mover's advantage were from stable, commoditized markets. But strategic marketing, or strategy of any kind, seemed rather irrelevant to much of the 90's VC-money-powered mindset.
IBM is cool now because they're actively 1) paying for linux advertising (related to IBM, but still), 2) writing lots of Linux articles, 3) contributing to linux, etc etc.
Not just Linux, mind! Let's not forget the Eclipse IDE, and a laundry list of various other smaller open source projects that IBM has released and/or sponsored.
While I'm at it, I'll plug a project that's recently made my life more pleasant: Aleks Totic's and Fabio Zadrozny's great work on PyDev, for Eclipse. From that site: "PyDev is a plugin that enables users to use Eclipse for Python development. It comes with many goodies such as code completion, syntax highlighting, syntax analysis, refactor, debug and many others."