My usage habits have changed as OSes have been upgraded. I use Dashboard and Spotlight all the time now.
Which is exactly what I didn't mean. The kinds of high-level tasks a user engages in are rather unlikely to have changed as a result of an OS upgrade alone. E.g. things such as "developing Ruby code", "playing music", or "working on a video project", etc. In your case, these are "doing arithmetic" and "checking a map". The apps involved should be irrelevant, especially in this case. Why? Because when you regard a system as a designed whole instead of "just a bunch of apps", then you can meaningfully talk about problems of the whole such as "my battery life tanked on upgrade". In this discussion, Dashboard or Spotlight, being parts of the designed whole (aka "the platform"), ideally shouldn't cause problems with power performance.
I stated that if they were doing drive intensive things, that would have an affect on the battery life.
Which, to spell it out, I ignored because it fails to give the benefit of the doubt regarding the original poster's intent -- that something seems to be causing a change in battery life BECAUSE of the upgrade. I like to think that they'd figure out that editing H.264 on a laptop would suck battery. The fan noise is a good clue to start with...
Point is that *I* don't know and *you* don't know either.
If you're going to sit around wallowing in The Socratic Truth, then why in the heck are you bothering to post at all? FWIW, my post wasn't about knowing or not knowing what's causing the OP's percieved battery life issues. I was addressing the plausiblity of Spotlight causing a battery life reduction being a real problem or not. An idea which you seemed to be dismissing, as you put it, by the "I don't know and you don't know" rationale.
What I recommend is that you check out what it is you are doing.
You blame the user's perception of a difference in battery life post OS upgrade to their usage habits? The user's work habits completely changed on an OS upgrade? I particularly like the implied solution that the user shouldn't do any work. Better: just turn it off and leave it plugged in at home. Lots of juice in the battery then.
Here's a clue: One big rule is to keep the hard drive spun down as much as possible. To this end, laptops and other portables use various strategies to defer disk accesses as long as possible (e.g. by caching writes in memory longer, etc). It's entirely reasonable to suspect that the additional disk interaction caused by Spotlight may reduce the OS' ability to defer and/or aggregate disk accesses. We already know that Spotlight itself has some warts (e.g. check out various Mac sites re: Spotlight and reindexing of large removable media drives.). It's very reasonable to suspect that the interaction between Spotlight and the system's ability to spin down disks hasn't been completely dialed in for laptop systems yet.
Q1. But forking is bad! [...] Homo Sapiens is a good example [of why forking can be a good thing].
A good example staying in the software world comes from GCC's history. In particular, the EGCS fork of the GCC compiler suite which eventually superseded the original codeline to officially regain the "GCC" moniker. Wikipedia has a nice summary of EGCS' history.
Until NX (No Execute) and good input sanitization is ubiquitous, these things will contine to plague the networked world.
Even these may not be enough. I think it's going to be really hard to get good, ubiquitous input sanitization. Folks will keep generating new and interesting dynamic, networked appplications, vulnerable in new and interesting ways...
A nice tip-of-the-iceberg example are notes on supported Python versions from the Zope team. They recommend Python 2.3.5, not the new 2.4.1, not for stability, but because they haven't had a chance to do a security audit of the new Python features in 2.4 to make sure that no security holes would be inadvertently created by running Zope on the newer Python release.
And is throwing his toys out of the pram because he's just not getting everything his way.
I disagree; IMO he's got a legitimate point. From the JWZ blog regarding problems with XMMS hogging all audio output such that no other apps can play audio:
I can't believe I even have to think about this shit. What year is it again?
This frustration highlights a failing of the Linux-based desktop platform. Put generally, Linux systems often require the user fuss with (and be aware of!) highly technical system tweaks to satisfy some really basic end-user scenarios. The blog's thread has lots of people going on about ways to fix this particular problem, but frankly I'm on JWZ's side: it's a damn waste of time! At least it is for those whom, the computer is a tool for getting work done, instead of an end in and of itself.
Put another way, I'm all for some degree of tweaking in my day-to-day usage. I find and install new tools, write helpful scripts/plugins/etc., and do other "meta-work" to make myself more productive. This process is kinda fun, too. But having to screw around for hours figuring out what to do just to get more than one app to play audio is insane.
And the real killer is that the solution is probably not to just roll up the ol' sleeves and write some software to "scratch the itch". This isn't a software problem, it's a real world problem of fragmented design and developer effort and a lack of a seamless out-of-box experience for Linux-based systems.
Getting fed up with that is hardly "throwing [your] toys out of the pram" -- it's called cutting your losses.
This will ultimately improve the tabs usability as an interface element by shallowing out the learning curve - what works in one program will work in another, unlike the examples you cite.
You're grossly oversimplifying things, resulting in your argument that reduces to the long-debunked argument for absolute consistency in the UI. Consistency is an important concept, but it's a subtle concept, not a design straightjacket. I don't have my HCI library at hand, but Shneiderman(sp?), et. al. and other good basic HCI texts should cover this. If there's something to your idea, you'll have to flesh it out a LOT more before it's a credible proposal. Even a single well thought out example would help.
As it happens, "what works in one program" pretty much does "work in another" as far as tabs are concerned -- a user clicks on the tab, and the associated "page" of information is revealed, "burying" other tabs. End of story. Some tabs do have app-dependent context menus, e.g. Firefox default has "New Tab, Reload Tab,..." But a tabbed preference box in an app doesn't need context menus on the tabs, nor does it need the operations "New Tab, Reload Tab,..." Moreover, window managers traditionally present a set of WM-based functions on context menus for UI elements they own. It's way beyond the WM's scope to interact with the app at this level. WM's know about window management, apps know about app semantics and presentation issues. Your proposal has the WM dabbling into app UI component semantics and presentation.
Beyond issues of consistency, X11 window managers are not app/UI frameworks and don't have the level of app integration required to effect much necessary basic functionality or create a satisfactory user experience with the diverse nature of apps that run under WMs. You're effectively arguing for a single, unified UI framework under X11, in which the WM plays a heavyweight role. This is not remotely the role that window managers play today. That's a *major* refactoring. The result is far beyond an extension to the X protocol or conventions; it simply wouldn't be X11 anymore.
WTF? Tabs in browsers and other apps are often are heavily dependent on the semantics of that particular application. Tabs can and have been made part of UI/Application frameworks, as the app can interact with those frameworks in a manner that makes the tabs sensible. The X11 window manager protocols are worlds removed from being UI/App frameworks. The protocols deliberately set up some uniform and non-intrusive ground rules to keep WMs from interfering with apps.
Moreover, look at the differences in use and presentation between "tabs" in most browsers today and apps such as spreadsheets, e.g. the multiple "sheets" model in Excel or Gnumeric. Likewise consdier tabs from the SWT toolkit used in Eclipse, Azureus (Java Bitorrent client), etc. These all have quite different uses and interaction models. Your proposal essentially amounts to "all tabs in all apps in all contexts should work just alike, and their visual display should no longer be controlled by the app." Doesn't seem like a very good idea to me...
Gark! "Nothing close to it." Thank goodness! Stroustrup's book practically requires that you already know the whole language before you crack the cover. Third edition is *much* better than prior editions on that point, which is a scary statement by itself.
Stroustrup's book is useful as a language reference, but far from a joy to read or use. Much like C++ itself, IMO. It's hardly "The One Book" for C++ -- the damn language is so hairy from both syntactic and semantic viewpoints that books such as Meyers' are necessary not just to get the most out of the language, but also to avoid the incredible number of pitfalls that C++ lays for the unwary.
virus will never have been easier to port, so does worm, spyware et al.
Sorry, but I need to put the smack-down on this right now. You haven't a damned clue about how this stuff works. Virii and worms depend largely on application-level "design features" or exploitable holes to get a foothold on a system. Virii, worms, and spyware also utilize system call and system library/framework calls to further establish that foothold and/or effect their individual program functions. These have nothing to do with the particular processor architecture.
Where processor architecture matters is in low-level binary exploit code such as the "shellcode" used to take advantage of a particular processor architecture. Simply put, anyone who's capable of actually writing shellcode for one platform can write it for another with a modicum additional effort and docs easily downloaded off the 'net.
The best example of this is a white-hat security company whose developers got tired of writing assembly. So they wrote a suite in Python that lets them give a high-level description of the exploit and target app parameters -- the Python code then generates the appropriate shellcode for every platform out there. Got a version of OpenSSH with a known exploit? Think you're safe 'cause you're on (SPARC, ARM, PPC, etc.?) Think again. These guys don't even have to click a button to do the translation; the high-level app just generates and tries various platform's shellcode, possibly hinted by system fingerprinting runs.
If there's any protection to be had, it's in the different OS platform layers (e.g. no ActiveX, radically different system libraries, etc.) rather than processor architectures.
iPods already use a SoC (system on a chip) main processor based on dual ARM cores, supplied by PortalPlayer, Inc. To be more specific, talks would have to surround StrongARM for iPods or another suitable Intel embedded offering.
Client firewalls are of limited utility. I don't understand why people bother with them.
Sigh. Look up "defense in depth" as it applies to system security.
If you need to provide access to a service, then you have to open its matching ports anyway.
What about folks with laptops in varied network environments, but who want to run services for local consumption? The Mac OS X Sharing pref pane in Panther either leaves your web server open to the world, or else turns the whole damn thing off. Offhand examples where localhost-only access are useful include any sort of web-based content work or development, as well as web-centric tools such as a laptop-local wiki installation.
Actually, I'd go even further than the grand-parent post did. I think the iPod domination is mostly marketing and hype.
I'll agree that there are a lot of iPod fanboys/fangirls. I'll also agree that Apple has aggressively (maybe even brilliantly...) marketed the iPod. Nevertheless, your list and random internet gripe-lists on "iPod problems" completely fail to capture the essence of what's great about the iPod's design. You're too focused on ultimately irrelevant (or outright nonexistant) problems to grasp what the iPod does right. And have no doubt, that essentially great design is the foundation that launched the iPod phenomenon -- no mere marketing clout.
In the historical view, the iPod was the first great MP3 player user interface. There were hard-drive based players before the iPod, but you felt seriously l33t if you could actually find your MP3's on the cursed things. The iPod gave the user a fast, fun, and intuitive interface that followed the KISS principle. This was an astonishing market break for the 1st-gen iPods. Consider also crtical features of the iPod such as blazing fast music transfers and single-cable ease of use made possible by Firewire, as well as the clean UI of iTunes compared to its contemporaries. Apple made the right design and engineering tradeoffs to hit the sweet-spot.
Moving forward in time, Apple certainly has taken advantage of its first-leader position in the market. Nevertheless, I still haven't seen much in the way of competition that's managed to present an entire package more compelling than the iPod. While you eschew the iPod as "way of life", the fact that it's built a marketplace of add-ons around it means that its feature list is effectively augmented by all of those accessories. What's better, you get to pay for only what you want.
Finally, the bullet list you present sounds like the sort of thing a bad marketing department comes up with. Bullet lists don't make a great design; they don't make any design. They aren't show-stoppers, they're nits. Likewise, much of Apple's competition is playing the wrong game. They're doing catch-up instead of leap-frog.
[Your list is also wrong in at least one item: I bought a replacement battery for my 1st gen iPod for about $30+shipping and did the installation myself. Works great with longer life than the original due to improved battery tech.]
Seems odd to me that they want media player removed, but still want to play media under certain conditions.
Why is this even remotely odd? It's just the difference between libraries and an application that uses those libraries. The equivalent operation on a Mac is trivial: just delete Quicktime Player from the Applications folder. As it happens, this won't affect any other Quicktime dependent application -- it just removes a single app.
On the surface, this appears to be the same BS that MS tried to play off in the US antitrust case regarding the bundling of IE. MS purposely chose a twisted interpretation of the scope of "Internet Explorer" to claim that IE was inseparable from the rest of the OS. That is, they chose to interpret "remove IE" to mean removal of not just the top-level application and/or icon, but of all related architectural components. That alleged inseparability was a mind-numbingly stupid claim to anyone with an iota of actual software development knowledge.
... bullshit! As well all the other major enterprises that have many thousants of deployed Linux boxen running business-critical software. These folks use Linux because 1) it's much more secure and securable than the competition, 2) it scales massively, 3) they can have their own fork (e.g. apply security patches, performance changes, etc. to the current production kernel version on their schedule, not some vendor's). Isn't it ironic how some of the uses of having your own "fork" improve scalability and security. 8-)
Let's not forget that it's far cheaper than the proprietary competition even for all of those benefits.
The Rollermouse is interesting, but IMO the coolest mouse/keyboard alternative out there remains the Fingerworks Touchstream Keyboard. It's a keyboard implemented as a touch surface. It's similar to a large laptop touchpad, except that the technology used forms an image of the hand in proximity to the keyboard surface (no "double touch" issues). This enables "zero-force typing", mousing, and programmable gesturing support. Typing does require a period of adjustment and retraining. The payoff is that your typing surface is also your mousing surface -- you'll never reach for that mouse again. E.g. for basic pointing, touch and move two fingers at a time. For drag/select just use three fingers -- no extra "click" is required. Other gestures support scrolling, 3-button mousing, copy, paste, undo/redo, etc. Various modes are available for application specific support, e.g. Emacs, Programmer's mode. IIRC, there are also modes (possibly user-contributed?) for graphics apps such as Photoshop, Maya, etc. Fingerworks' open-source XWinder tool further enables window-manipulation (move, resize, etc.) gestures on various OSes.
The Touchstream requires no drivers beyond standard USB keyboard/mouse support, so it'll work out of the box with just about any modern OS out there.
While the Touchstream is somewhat spendy, there are also the more reasonably priced iGesture pads, think of a mouse-pad with a USB cable (and no mouse). These handle mousing, gesture recognition, and optionally numpad or mini-QWERTY keyboards. This is also nice option for folks who want to keep their conventional keyboard, but add the advantages of gesturing support.
(Std. Disclaimer: I have no business relationship w/ these folks, I just think they have a great product...)
I'd be more concerned about someone else hopping on your computer when ProspectiveEmployer91241 sends a message to you...
Let's get this straight: lock your damn computer when you leave it. This is the single easiest thing to do to protect yourself from co-workers or managers with misguided intentions, whether clueless or malicious. Locking is trivial to do in most environments; Windows users have the single default keybinding of <Windows Key>-l (lowercase L). No need to even bother with Ctrl-Alt-Del. Other OSes (Mac OS X, Linux, various Unices) are similarly easy to set up for screen locking, usually via a password-enabled screensaver.
This has another great side-benefit: you will rarely forget even a totally line-noise password ever again. Change your password in the morning (preferably not on a Friday), and you'll type it in a number of times that day, and for the next few days.
First, you seem to assume that there should be a license monoculture. While that eases the learning curve, it isn't necessarily realistic. Each of GPL and BSD licenses has its place today. The GPL works very well for projects that need to establish a "community space" for sharing work. It has been especially successful, IMO, in projects where many parties can come together to distribute the effort of "infrastructure" -- code that would otherwise be a cost-center for everyone involved. The Linux kernel itself is a great example of this. BSD is highly appropriate for projects that prioritize the utility of the work to all parties over the community sharing ethos. It proven to be especially relevant to reference implementations of standards, where acceptance and deployment of the standard itself is more important than any code that merely implements it.
Second, you ignore dual (or N-way) licensing. For example, the folks that released FFTW (Fastest Fourier Transform in the West) at MIT did so with the blessing of the university because they could dual license. Researchers and those willing to contribute back to the work as a community effort reaped the benefits, while commercial entities with different licensing needs could pay as usual.
The Zesiger License is an interesting compromise, but I'm unclear as to how it would work in practice. The GPL and BSD licenses have "social" properties that have proved very valuable to certain projects. Zesiger may simply be another point in a continuum, useful to some, less so to others. Also, it'd be nice if Zesiger or a variant had an escrow clause to help avoid "lost" code, e.g. because the company failed, creator had no backups and a hard drive crash one month before the release deadline, etc. Maybe extend SourceForge with "SourceVault" -- pages with little timers on 'em. 8-)
As some have pointed out, we need business models that will support all the kinds of works that developers produce and users require. Licenses themselves create community rules that support or inhibit certain kinds of interaction, and thus certain ways of users obtaining support and developers earning a living. While it'd be great to have a "silver bullet" license that found that mythical perfect balance, I'm not yet convinced that goal is practical or even possible.
To date, I've never heard of a decorative rule that did add to the aesthetics, but I'm willing to concede that it is possible such rules exist.
A good example of these are the unwritten rules of social etiquette, aka "being polite". One example: Holding the door for folks, even when they don't "need" you to do it.
Another example, especially for our U.S. readers: in Paris (and France generally) it is customary for shopkeepers and customers to greet one another as customers enter and leave the store. Recall that small non-chain storefronts (often owner-operated) are the norm in Europe. For most occasions (and non-French speakers), a simple "bonjour/bonsoir" suffices. Note that this isn't the U.S. institutionalized phenomenon of the "greeter" -- someone stuck at the front of the store whose job it is to bleat a greeting. This custom doesn't seem like much, in that society would hardly come crashing down without it. But it makes quite a difference in the quality of day-to-day experience when you're actually living with it. Specifically, visit France and live with these customs for about a week. When you leave, you'll find out just how jarring it is to go back to the abrupt U.S.-style of doing things.
I'm sorry, but your post is the single biggest misunderstanding of the concepts of both computer security and operating system fundamentals that I've ever seen. I give an F in these subjects to your moderators, who pumped you up to +5, Insightful.
First, I'll summarize your larger point as "just because you can doesn't mean you should." Sorry, buddy, but this logic just doesn't scale. Put another way, you've got a Utopian assumption hidden in there. By your reasoning, doors shouldn't have locks on them, cause we should all just know better. Apparently teenagers and theives don't exist in your universe.
Second, to the specific issues w.r.t. "unix security" that you bring up:
The entire point of an operating system is to manage limited system resources. Things like disk quotas and process limits have little to do with "security", and everything to do with resource management in a multi-user, multi-process environment. Recall that 1) software has bugs and 2) individual users will, by mundane human nature alone, suck up resources until *something* stops them. While various resource limiters do help against certain local DoS attacks, it's not like these tools were primarily conceived as "security" devices. They're designed to manage shared resources in a manner that promotes system stability.
Whether it's users storing endless pr0n archives, Comp Sci students writing My First fork() Program, or buggy software, resource limits are a handy tool for maintaining the operation and stability of systems with lots of people and processes competing for resources.
A well configured, well patched Windows machine (especially a server) isn't going to be very vulnerable.
That's true as long as you say directly vulnerable. However, in any IT shop you also need to consider indirect vulnerabilities. E.g. the server itself may be secure, but someone's got to administer that system periodically. How secure are the system(s) used by the admins, or other systems on the network? All an attacker needs are some common user apps w/ holes on *some* systems that connect to the open internet (e.g. email, web browsers). With such a foothold established, the internal network and systems become subject to further analysis and attack. Small steps until the target is attained...
In short, a well set-up server is like having good basic household security: locks on doors and properly secured windows. These methods are useful, but simply won't stop a determined attacker.
That was likely either just uuencoded, or better still, a shell (aka shar) archive.
Long live net.sources! (Sighs wistfully for the days when Usenet failed to suck...)
What a unique definition of "news reporting"
on
Think Secret Gets Lawyer
·
· Score: 1, Interesting
Apple's attempt to silence a small publication's news reporting [...]
Maybe I'm missing something here, but I just don't get what the ruckus is about this suit. Calling the ThinkSecret publications that caused this suit "news reporting" seems disingenuous to me. Why? Because TS' model seems to be to solicit insider information from within Apple, likely in violation of both trade secret law and the hiring/IP contracts of those who leaked the information. Also, Apple's main aim in this is to find the leaks in its organization. Casting this as "Apple vs. ThinkSecret" also seems like BS, unless this is cast as some sort of yellow-journalism, David v. Goliath type of slant.
An interesting question this suit raises is: where is the line between "news reporting" and "any random schmoe with a blog/website"? What, if any, legal protections and judicial precedents apply to "news" reporters relevant to this context?
Ah, heat dissipation and graphics engines. That brings back memories of working in the local University graphics lab one summer doing some project work. Alas, the HVAC vents for the room were stuck full-open; the place was freezing cold. To combat this, I'd make sure the old GE Graphicon graphics engine (at the time, very high-end) under the desk of my workstation was turned on... it was a _very_ effective space heater. 8-)
"Local" != "Console". This isn't about physical access. Kernel privilege escalation attacks are like gold to someone trying to take over a system. It allows any non-root remote exploit to be turned into a remote root exploit. To really spell it out:
Step 1: Attack any non-root remote exploit, establish a non-root shellcode "beachead". Step 2: Run this attack on an unpatched system. Step 3: There is no step 3; the box is 0wned.
This is a *very* serious problem. Linux folks, patch your systems ASAP.
Slashdot Mirror
My usage habits have changed as OSes have been upgraded. I use Dashboard and Spotlight all the time now.
Which is exactly what I didn't mean. The kinds of high-level tasks a user engages in are rather unlikely to have changed as a result of an OS upgrade alone. E.g. things such as "developing Ruby code", "playing music", or "working on a video project", etc. In your case, these are "doing arithmetic" and "checking a map". The apps involved should be irrelevant, especially in this case. Why? Because when you regard a system as a designed whole instead of "just a bunch of apps", then you can meaningfully talk about problems of the whole such as "my battery life tanked on upgrade". In this discussion, Dashboard or Spotlight, being parts of the designed whole (aka "the platform"), ideally shouldn't cause problems with power performance.
I stated that if they were doing drive intensive things, that would have an affect on the battery life.
Which, to spell it out, I ignored because it fails to give the benefit of the doubt regarding the original poster's intent -- that something seems to be causing a change in battery life BECAUSE of the upgrade. I like to think that they'd figure out that editing H.264 on a laptop would suck battery. The fan noise is a good clue to start with...
Point is that *I* don't know and *you* don't know either.
If you're going to sit around wallowing in The Socratic Truth, then why in the heck are you bothering to post at all? FWIW, my post wasn't about knowing or not knowing what's causing the OP's percieved battery life issues. I was addressing the plausiblity of Spotlight causing a battery life reduction being a real problem or not. An idea which you seemed to be dismissing, as you put it, by the "I don't know and you don't know" rationale.
What I recommend is that you check out what it is you are doing.
You blame the user's perception of a difference in battery life post OS upgrade to their usage habits? The user's work habits completely changed on an OS upgrade? I particularly like the implied solution that the user shouldn't do any work. Better: just turn it off and leave it plugged in at home. Lots of juice in the battery then.
Here's a clue: One big rule is to keep the hard drive spun down as much as possible. To this end, laptops and other portables use various strategies to defer disk accesses as long as possible (e.g. by caching writes in memory longer, etc). It's entirely reasonable to suspect that the additional disk interaction caused by Spotlight may reduce the OS' ability to defer and/or aggregate disk accesses. We already know that Spotlight itself has some warts (e.g. check out various Mac sites re: Spotlight and reindexing of large removable media drives.). It's very reasonable to suspect that the interaction between Spotlight and the system's ability to spin down disks hasn't been completely dialed in for laptop systems yet.
Q1. But forking is bad!
[...]
Homo Sapiens is a good example [of why forking can be a good thing].
A good example staying in the software world comes from GCC's history. In particular, the EGCS fork of the GCC compiler suite which eventually superseded the original codeline to officially regain the "GCC" moniker. Wikipedia has a nice summary of EGCS' history.
Until NX (No Execute) and good input sanitization is ubiquitous, these things will contine to plague the networked world.
Even these may not be enough. I think it's going to be really hard to get good, ubiquitous input sanitization. Folks will keep generating new and interesting dynamic, networked appplications, vulnerable in new and interesting ways...
A nice tip-of-the-iceberg example are notes on supported Python versions from the Zope team. They recommend Python 2.3.5, not the new 2.4.1, not for stability, but because they haven't had a chance to do a security audit of the new Python features in 2.4 to make sure that no security holes would be inadvertently created by running Zope on the newer Python release.
I disagree; IMO he's got a legitimate point. From the JWZ blog regarding problems with XMMS hogging all audio output such that no other apps can play audio:
This frustration highlights a failing of the Linux-based desktop platform. Put generally, Linux systems often require the user fuss with (and be aware of!) highly technical system tweaks to satisfy some really basic end-user scenarios. The blog's thread has lots of people going on about ways to fix this particular problem, but frankly I'm on JWZ's side: it's a damn waste of time! At least it is for those whom, the computer is a tool for getting work done, instead of an end in and of itself.
Put another way, I'm all for some degree of tweaking in my day-to-day usage. I find and install new tools, write helpful scripts/plugins/etc., and do other "meta-work" to make myself more productive. This process is kinda fun, too. But having to screw around for hours figuring out what to do just to get more than one app to play audio is insane.
And the real killer is that the solution is probably not to just roll up the ol' sleeves and write some software to "scratch the itch". This isn't a software problem, it's a real world problem of fragmented design and developer effort and a lack of a seamless out-of-box experience for Linux-based systems.
Getting fed up with that is hardly "throwing [your] toys out of the pram" -- it's called cutting your losses.
This will ultimately improve the tabs usability as an interface element by shallowing out the learning curve - what works in one program will work in another, unlike the examples you cite.
..." But a tabbed preference box in an app doesn't need context menus on the tabs, nor does it need the operations "New Tab, Reload Tab, ..." Moreover, window managers traditionally present a set of WM-based functions on context menus for UI elements they own. It's way beyond the WM's scope to interact with the app at this level. WM's know about window management, apps know about app semantics and presentation issues. Your proposal has the WM dabbling into app UI component semantics and presentation.
You're grossly oversimplifying things, resulting in your argument that reduces to the long-debunked argument for absolute consistency in the UI. Consistency is an important concept, but it's a subtle concept, not a design straightjacket. I don't have my HCI library at hand, but Shneiderman(sp?), et. al. and other good basic HCI texts should cover this. If there's something to your idea, you'll have to flesh it out a LOT more before it's a credible proposal. Even a single well thought out example would help.
As it happens, "what works in one program" pretty much does "work in another" as far as tabs are concerned -- a user clicks on the tab, and the associated "page" of information is revealed, "burying" other tabs. End of story. Some tabs do have app-dependent context menus, e.g. Firefox default has "New Tab, Reload Tab,
Beyond issues of consistency, X11 window managers are not app/UI frameworks and don't have the level of app integration required to effect much necessary basic functionality or create a satisfactory user experience with the diverse nature of apps that run under WMs. You're effectively arguing for a single, unified UI framework under X11, in which the WM plays a heavyweight role. This is not remotely the role that window managers play today. That's a *major* refactoring. The result is far beyond an extension to the X protocol or conventions; it simply wouldn't be X11 anymore.
WTF? Tabs in browsers and other apps are often are heavily dependent on the semantics of that particular application. Tabs can and have been made part of UI/Application frameworks, as the app can interact with those frameworks in a manner that makes the tabs sensible. The X11 window manager protocols are worlds removed from being UI/App frameworks. The protocols deliberately set up some uniform and non-intrusive ground rules to keep WMs from interfering with apps.
Moreover, look at the differences in use and presentation between "tabs" in most browsers today and apps such as spreadsheets, e.g. the multiple "sheets" model in Excel or Gnumeric. Likewise consdier tabs from the SWT toolkit used in Eclipse, Azureus (Java Bitorrent client), etc. These all have quite different uses and interaction models. Your proposal essentially amounts to "all tabs in all apps in all contexts should work just alike, and their visual display should no longer be controlled by the app." Doesn't seem like a very good idea to me...
Gark! "Nothing close to it." Thank goodness! Stroustrup's book practically requires that you already know the whole language before you crack the cover. Third edition is *much* better than prior editions on that point, which is a scary statement by itself.
Stroustrup's book is useful as a language reference, but far from a joy to read or use. Much like C++ itself, IMO. It's hardly "The One Book" for C++ -- the damn language is so hairy from both syntactic and semantic viewpoints that books such as Meyers' are necessary not just to get the most out of the language, but also to avoid the incredible number of pitfalls that C++ lays for the unwary.
virus will never have been easier to port, so does worm, spyware et al.
Sorry, but I need to put the smack-down on this right now. You haven't a damned clue about how this stuff works. Virii and worms depend largely on application-level "design features" or exploitable holes to get a foothold on a system. Virii, worms, and spyware also utilize system call and system library/framework calls to further establish that foothold and/or effect their individual program functions. These have nothing to do with the particular processor architecture.
Where processor architecture matters is in low-level binary exploit code such as the "shellcode" used to take advantage of a particular processor architecture. Simply put, anyone who's capable of actually writing shellcode for one platform can write it for another with a modicum additional effort and docs easily downloaded off the 'net.
The best example of this is a white-hat security company whose developers got tired of writing assembly. So they wrote a suite in Python that lets them give a high-level description of the exploit and target app parameters -- the Python code then generates the appropriate shellcode for every platform out there. Got a version of OpenSSH with a known exploit? Think you're safe 'cause you're on (SPARC, ARM, PPC, etc.?) Think again. These guys don't even have to click a button to do the translation; the high-level app just generates and tries various platform's shellcode, possibly hinted by system fingerprinting runs.
If there's any protection to be had, it's in the different OS platform layers (e.g. no ActiveX, radically different system libraries, etc.) rather than processor architectures.
ARM for iPods maybe
iPods already use a SoC (system on a chip) main processor based on dual ARM cores, supplied by PortalPlayer, Inc. To be more specific, talks would have to surround StrongARM for iPods or another suitable Intel embedded offering.
they say they'll go private and their stocks spike, they sell some stock and make alittle money
Really? Do you have any way to back that up? If so, some fine folks at the SEC would be deeply interested. Insider trading is just a wee bit illegal.
Client firewalls are of limited utility. I don't understand why people bother with them.
Sigh. Look up "defense in depth" as it applies to system security.
If you need to provide access to a service, then you have to open its matching ports anyway.
What about folks with laptops in varied network environments, but who want to run services for local consumption? The Mac OS X Sharing pref pane in Panther either leaves your web server open to the world, or else turns the whole damn thing off. Offhand examples where localhost-only access are useful include any sort of web-based content work or development, as well as web-centric tools such as a laptop-local wiki installation.
Actually, I'd go even further than the grand-parent post did. I think the iPod domination is mostly marketing and hype.
I'll agree that there are a lot of iPod fanboys/fangirls. I'll also agree that Apple has aggressively (maybe even brilliantly...) marketed the iPod. Nevertheless, your list and random internet gripe-lists on "iPod problems" completely fail to capture the essence of what's great about the iPod's design. You're too focused on ultimately irrelevant (or outright nonexistant) problems to grasp what the iPod does right. And have no doubt, that essentially great design is the foundation that launched the iPod phenomenon -- no mere marketing clout.
In the historical view, the iPod was the first great MP3 player user interface. There were hard-drive based players before the iPod, but you felt seriously l33t if you could actually find your MP3's on the cursed things. The iPod gave the user a fast, fun, and intuitive interface that followed the KISS principle. This was an astonishing market break for the 1st-gen iPods. Consider also crtical features of the iPod such as blazing fast music transfers and single-cable ease of use made possible by Firewire, as well as the clean UI of iTunes compared to its contemporaries. Apple made the right design and engineering tradeoffs to hit the sweet-spot.
Moving forward in time, Apple certainly has taken advantage of its first-leader position in the market. Nevertheless, I still haven't seen much in the way of competition that's managed to present an entire package more compelling than the iPod. While you eschew the iPod as "way of life", the fact that it's built a marketplace of add-ons around it means that its feature list is effectively augmented by all of those accessories. What's better, you get to pay for only what you want.
Finally, the bullet list you present sounds like the sort of thing a bad marketing department comes up with. Bullet lists don't make a great design; they don't make any design. They aren't show-stoppers, they're nits. Likewise, much of Apple's competition is playing the wrong game. They're doing catch-up instead of leap-frog.
[Your list is also wrong in at least one item: I bought a replacement battery for my 1st gen iPod for about $30+shipping and did the installation myself. Works great with longer life than the original due to improved battery tech.]
Seems odd to me that they want media player removed, but still want to play media under certain conditions.
Why is this even remotely odd? It's just the difference between libraries and an application that uses those libraries. The equivalent operation on a Mac is trivial: just delete Quicktime Player from the Applications folder. As it happens, this won't affect any other Quicktime dependent application -- it just removes a single app.
On the surface, this appears to be the same BS that MS tried to play off in the US antitrust case regarding the bundling of IE. MS purposely chose a twisted interpretation of the scope of "Internet Explorer" to claim that IE was inseparable from the rest of the OS. That is, they chose to interpret "remove IE" to mean removal of not just the top-level application and/or icon, but of all related architectural components. That alleged inseparability was a mind-numbingly stupid claim to anyone with an iota of actual software development knowledge.
... bullshit! As well all the other major enterprises that have many thousants of deployed Linux boxen running business-critical software. These folks use Linux because 1) it's much more secure and securable than the competition, 2) it scales massively, 3) they can have their own fork (e.g. apply security patches, performance changes, etc. to the current production kernel version on their schedule, not some vendor's). Isn't it ironic how some of the uses of having your own "fork" improve scalability and security. 8-)
Let's not forget that it's far cheaper than the proprietary competition even for all of those benefits.
The Rollermouse is interesting, but IMO the coolest mouse/keyboard alternative out there remains the Fingerworks Touchstream Keyboard. It's a keyboard implemented as a touch surface. It's similar to a large laptop touchpad, except that the technology used forms an image of the hand in proximity to the keyboard surface (no "double touch" issues). This enables "zero-force typing", mousing, and programmable gesturing support. Typing does require a period of adjustment and retraining. The payoff is that your typing surface is also your mousing surface -- you'll never reach for that mouse again. E.g. for basic pointing, touch and move two fingers at a time. For drag/select just use three fingers -- no extra "click" is required. Other gestures support scrolling, 3-button mousing, copy, paste, undo/redo, etc. Various modes are available for application specific support, e.g. Emacs, Programmer's mode. IIRC, there are also modes (possibly user-contributed?) for graphics apps such as Photoshop, Maya, etc. Fingerworks' open-source XWinder tool further enables window-manipulation (move, resize, etc.) gestures on various OSes.
The Touchstream requires no drivers beyond standard USB keyboard/mouse support, so it'll work out of the box with just about any modern OS out there.
While the Touchstream is somewhat spendy, there are also the more reasonably priced iGesture pads, think of a mouse-pad with a USB cable (and no mouse). These handle mousing, gesture recognition, and optionally numpad or mini-QWERTY keyboards. This is also nice option for folks who want to keep their conventional keyboard, but add the advantages of gesturing support.
(Std. Disclaimer: I have no business relationship w/ these folks, I just think they have a great product...)
I'd be more concerned about someone else hopping on your computer when ProspectiveEmployer91241 sends a message to you...
Let's get this straight: lock your damn computer when you leave it. This is the single easiest thing to do to protect yourself from co-workers or managers with misguided intentions, whether clueless or malicious. Locking is trivial to do in most environments; Windows users have the single default keybinding of <Windows Key>-l (lowercase L). No need to even bother with Ctrl-Alt-Del. Other OSes (Mac OS X, Linux, various Unices) are similarly easy to set up for screen locking, usually via a password-enabled screensaver.
This has another great side-benefit: you will rarely forget even a totally line-noise password ever again. Change your password in the morning (preferably not on a Friday), and you'll type it in a number of times that day, and for the next few days.
You have a few incorrect assumptions in there.
First, you seem to assume that there should be a license monoculture. While that eases the learning curve, it isn't necessarily realistic. Each of GPL and BSD licenses has its place today. The GPL works very well for projects that need to establish a "community space" for sharing work. It has been especially successful, IMO, in projects where many parties can come together to distribute the effort of "infrastructure" -- code that would otherwise be a cost-center for everyone involved. The Linux kernel itself is a great example of this. BSD is highly appropriate for projects that prioritize the utility of the work to all parties over the community sharing ethos. It proven to be especially relevant to reference implementations of standards, where acceptance and deployment of the standard itself is more important than any code that merely implements it.
Second, you ignore dual (or N-way) licensing. For example, the folks that released FFTW (Fastest Fourier Transform in the West) at MIT did so with the blessing of the university because they could dual license. Researchers and those willing to contribute back to the work as a community effort reaped the benefits, while commercial entities with different licensing needs could pay as usual.
The Zesiger License is an interesting compromise, but I'm unclear as to how it would work in practice. The GPL and BSD licenses have "social" properties that have proved very valuable to certain projects. Zesiger may simply be another point in a continuum, useful to some, less so to others. Also, it'd be nice if Zesiger or a variant had an escrow clause to help avoid "lost" code, e.g. because the company failed, creator had no backups and a hard drive crash one month before the release deadline, etc. Maybe extend SourceForge with "SourceVault" -- pages with little timers on 'em. 8-)
As some have pointed out, we need business models that will support all the kinds of works that developers produce and users require. Licenses themselves create community rules that support or inhibit certain kinds of interaction, and thus certain ways of users obtaining support and developers earning a living. While it'd be great to have a "silver bullet" license that found that mythical perfect balance, I'm not yet convinced that goal is practical or even possible.
To date, I've never heard of a decorative rule that did add to the aesthetics, but I'm willing to concede that it is possible such rules exist.
A good example of these are the unwritten rules of social etiquette, aka "being polite". One example: Holding the door for folks, even when they don't "need" you to do it.
Another example, especially for our U.S. readers: in Paris (and France generally) it is customary for shopkeepers and customers to greet one another as customers enter and leave the store. Recall that small non-chain storefronts (often owner-operated) are the norm in Europe. For most occasions (and non-French speakers), a simple "bonjour/bonsoir" suffices. Note that this isn't the U.S. institutionalized phenomenon of the "greeter" -- someone stuck at the front of the store whose job it is to bleat a greeting. This custom doesn't seem like much, in that society would hardly come crashing down without it. But it makes quite a difference in the quality of day-to-day experience when you're actually living with it. Specifically, visit France and live with these customs for about a week. When you leave, you'll find out just how jarring it is to go back to the abrupt U.S.-style of doing things.
I'm sorry, but your post is the single biggest misunderstanding of the concepts of both computer security and operating system fundamentals that I've ever seen. I give an F in these subjects to your moderators, who pumped you up to +5, Insightful.
First, I'll summarize your larger point as "just because you can doesn't mean you should." Sorry, buddy, but this logic just doesn't scale. Put another way, you've got a Utopian assumption hidden in there. By your reasoning, doors shouldn't have locks on them, cause we should all just know better. Apparently teenagers and theives don't exist in your universe.
Second, to the specific issues w.r.t. "unix security" that you bring up:
The entire point of an operating system is to manage limited system resources. Things like disk quotas and process limits have little to do with "security", and everything to do with resource management in a multi-user, multi-process environment. Recall that 1) software has bugs and 2) individual users will, by mundane human nature alone, suck up resources until *something* stops them. While various resource limiters do help against certain local DoS attacks, it's not like these tools were primarily conceived as "security" devices. They're designed to manage shared resources in a manner that promotes system stability.
Whether it's users storing endless pr0n archives, Comp Sci students writing My First fork() Program, or buggy software, resource limits are a handy tool for maintaining the operation and stability of systems with lots of people and processes competing for resources.
A well configured, well patched Windows machine (especially a server) isn't going to be very vulnerable.
That's true as long as you say directly vulnerable. However, in any IT shop you also need to consider indirect vulnerabilities. E.g. the server itself may be secure, but someone's got to administer that system periodically. How secure are the system(s) used by the admins, or other systems on the network? All an attacker needs are some common user apps w/ holes on *some* systems that connect to the open internet (e.g. email, web browsers). With such a foothold established, the internal network and systems become subject to further analysis and attack. Small steps until the target is attained...
In short, a well set-up server is like having good basic household security: locks on doors and properly secured windows. These methods are useful, but simply won't stop a determined attacker.
using some archaic app (binhex, maybe)
That was likely either just uuencoded, or better still, a shell (aka shar) archive.
Long live net.sources! (Sighs wistfully for the days when Usenet failed to suck...)
Apple's attempt to silence a small publication's news reporting [...]
Maybe I'm missing something here, but I just don't get what the ruckus is about this suit. Calling the ThinkSecret publications that caused this suit "news reporting" seems disingenuous to me. Why? Because TS' model seems to be to solicit insider information from within Apple, likely in violation of both trade secret law and the hiring/IP contracts of those who leaked the information. Also, Apple's main aim in this is to find the leaks in its organization. Casting this as "Apple vs. ThinkSecret" also seems like BS, unless this is cast as some sort of yellow-journalism, David v. Goliath type of slant.
An interesting question this suit raises is: where is the line between "news reporting" and "any random schmoe with a blog/website"? What, if any, legal protections and judicial precedents apply to "news" reporters relevant to this context?
Ah, heat dissipation and graphics engines. That brings back memories of working in the local University graphics lab one summer doing some project work. Alas, the HVAC vents for the room were stuck full-open; the place was freezing cold. To combat this, I'd make sure the old GE Graphicon graphics engine (at the time, very high-end) under the desk of my workstation was turned on... it was a _very_ effective space heater. 8-)
"Local" != "Console". This isn't about physical access. Kernel privilege escalation attacks are like gold to someone trying to take over a system. It allows any non-root remote exploit to be turned into a remote root exploit. To really spell it out:
Step 1: Attack any non-root remote exploit, establish a non-root shellcode "beachead".
Step 2: Run this attack on an unpatched system.
Step 3: There is no step 3; the box is 0wned.
This is a *very* serious problem. Linux folks, patch your systems ASAP.