I like how all the other replies get hung up on the throwaway "why is this news" comment, but none draws attention to the brilliant product release schedule suggestion. Why not do something like this? Hm?
I've been browsing Slashdot without the slashboxes for years now, but I'd turn them all back on just to get one that did what you're describing here. Heck, you could even set up different ones for different sections, so the main page would get the cross-platform and most-popular items (Firefox, Linux kernel, OSX release, etc) and the sections would get ones that were appropriate to them (e.g. the Apple one could have versions of Safari, Firefox, Camino, iTunes, OSX, etc; a Windows one (say, why is there no Windows section?) could have recent hotfixes, service packs, etc.
As a bonus, the "last update" item could link to the article about the most recent release, while the "product" link can link to a search for all the release articles for that product. And with everything bundled up there, the release articles could be moved off the front page and we'd get less of this whining about new releases not being newsworthy events.
I don't suppose there's any chance that this could be implemented, could it?
I guess they're just not that worried in investing the 59 seconds it would take to placate both of the world's Ogg users.
I can't blame them, really. They seem to be doing pretty well so far by ignoring these Ogg fanatics (both of which, aside from incessant Slashdot whining, don't ever actually seem to show up in real life).
Not to nitpick, but wouldn't the computer with a "one" in the name be more usefully thought of as the one that started it all ?
And that's not even getting into earlier computers that can be thought of as having started it all (EVIAC anyone?) or proto-computers (*ahem* Babbage's Difference and Analytical Engines) or proto-proto-computers (the Jacquard loom, the abacus, etc), or more broadly, the things that *really* started it all (the Big Bang, the original monocellular organisms, or for the people in Kansas, pick your fairy tale of choice).
Maybe we should have clarified what "it" is that was "all started". But it's too late now...
This might be what you're looking for: using screen to share console apps.
[....]
Note that I have the screen session detach. Type "screen -ls" to get the screen session name (for the other person), then type "screen -r" to reattach. The other person ssh'd into my machine and typed "screen -x session_name". It is possible to script all of this to make it easier.
We then talked over the phone (headphones highly recommended) while we could simultaneously edit in a vi session. It was hilarious because we'd start yelling at each other "No,no, let ME type." Still, these sessions are always among my most productive programming sessions because we catch each others mistakes and program the parts of the program that we have expertise in.
No, it isn't. This is a crude, crude simulation of what SEE allows people to do cleanly, painlessly, and transparently. As noted in one of the URLs I linked to previously, screen is not equivalent to what SubEthaEdit is doing, because unlike pretty much every other editor ever, SubEthaEdit supports multiple concurrent insertion points.
Yes, you can use screen to share a Vim or Emacs session among multiple people, but they're all still going to have to haggle over who gets to type at any one time. With SEE, on the other hand, everyone can work independently, in the same or in different regions of the same file, and everyone is always looking at the current, collaboratively written version of the same document. To keep things from getting confusing, all the edits I make will have a white background, and all the edits you make will have a pale green background, and all the edits that another person makes will have a sky blue background, and so on and so forth. And this is independent of syntax highlighting, so you also get nicely multicolored text over these multicolored backgrounds.
This is, in short, light years ahead of anything that you could cobble together with Emacs or Vi in a screen session.
By way of comparison, consider VNC. You can share a VNC session such that the console user and one or more observers are sharing the mouse pointer and keyboard input, but you still only get one mouse cursor and one flow of keyboard input, so if I pull left and you pull right, the competition for the cursor cancels out and the pointer ends up somewhere in the middle. With the SEE protocol, by contrast, it's as if every participant gets their own mouse and keyboard, so I can open & work in windows in one corner of the screen, and you can do similar work in another, and if we want, we can work on each other's regions of the screen. (And yes, this would require a bit of cooperation to avoid chaos, but maybe the cursors would be visible on all shared displays, with flags by each cursor to highlight who is working where, so that you could understand at a glance what's going on.)
Spend 30 seconds collaborating with SEE, and you'll realize what a cruel joke of a collaboration method screen-shared Vi/Emacs is...
Moreover, they've writtenseveraltimes that SubEthaEdit leverages several OSX technologies, including both Bonjour and Cocoa, as well as makes (unorthodox?) use of open protcols like BEEP. From the sound of it, getting SEE to work without this toolkit would be very hard to do.
I'm a little more interested in support for the SEE protocol in an editor like Vim or Emacs. If they can add it, then it'll instantly be available to people using any platform at all, even if SEE never gets ported to anything else. From what I can tell, this is a lot more likely, but so far I haven't heard of anyone working on hacking up these editors to support SEE style collaborative editing. Oh well...
I agree that all browsers available should be supported generally, but the issue here is: zero-configuration networking, enables automatic discovery of computers, devices, and services on IP networks. These things are Operating System issues, the only reason they call it Internet Explorer plugin is probably that it is the file-manager. Opera and Mozilla are not file managers, thus they do not need a plugin to browse available printers etc on the LAN, and they will not work unless the underlying operating system has configured the network etc.:-)
Well, it's sort of an OS issue, and it's sort of an application issue.
The support for automatic resource discovery should be provided by the operating system, yes, but applications need to integrate this in appropriate ways. Web browsers, for example, need to actually ask for that information, and need to provide an interface for accessing it.
It doesn't really have anything to do with IE's file managing capabilities. With the new version of Bonjour for Windows, Apple has provided a plugin that allows IE users to browse local Rendezvous^W Bonjour HTTP resources from directly in the browser, via both a toolbar icon and a menu option, both of which open up an Explorer Bar panel on the left side of the browser window -- similar to the standard history / media / folders / etc views -- that shows a list of current Rendezvous^H^H^H Bonjour advertised URLs. While the OS, by way of the Bonjour subsystem, is providing the mechanism for finding these resources, the plugin for IE is a separate component that exploits that subsystem from within IE. You need both halves to do anything useful with this.
And boy is this ever useful. At my job, I'm already using the mod_rendezvous_apple^W mod_bonjour Apache module to advertise a list of URLs for things useful to all the staff here -- the phone book, the intranet search engine, the bug tracker, the documentation wiki, etc -- so that all the users of Bonjour capable browsers automatically get a shared bookmark list. So far, this has only been useful for the people using OSX and Safari or Camino, but now it'll be useful to the people using IE on Windows. This would be great, were it not for the fact that we've managed to migrate almost all the Windows users over to Firefox by now. What would be really useful would be for Apple to bundle a Firefox plugin, or for Mozdev or someone to provide one that takes advantage of the Bonjour for Windows [and Linux!] API. If that became available, then everyone would be able to benefit from these automatically advertised resources.
The next step might be to come up with a CUPS/Bonjour bridge, so that the Windows users can automatically discover the CUPS printers in the same way that the OSX and Linux users can. I assume it should be possible...
So I don't blame Apple for getting rid of that SYSV stuff. It might have been cool back in the day, but it has lost its luster.
The Unix layer of OSX is BSD based, and in fact was in sync with FreeBSD as of Panther in 2003, and (presumably) is in sync with... whatever the current release of FreeBSD is as of this spring, as of Tiger. So there was no "SYSV stuff" to get rid of in OSX.
OSX already had their own approacch to startup from 10.0 through 10.3 that looked nothing like any other *NIX I've had exposure to -- Linux (RedHat, SuSE, Debian), Solaris, or Irix. It was their own thing, where bundles of XML definition files and executable scripts (typically Bourne shell scripts, but in principle they could be Perl or Python or something compiled or whatever) live in {/System,}/Library/StartupItems/Service. This system was a little weird, but once you got used to it, the design was very clean.
But "very clean", apparently, wasn't good enough. Now, launchd replaces this entire approach, along with a whole bunch of other traditional Unix cruft. It's actually a radical rethinking of how all these things have been done by every Unix vendor for the last 30 years, and from the looks of it, it's a huge step forward.
I'll be very disappointed if other systems don't pick this up.
Hmm, well... I'm using QuickTime 7 on 10.3, and the QuickTime web site has a little bit that says... "Use QuickTime Player in Mac OS X Tiger or get QuickTime 7 for Panther to see for yourself.:)
Yes, and if you'd read the entire post that you're replying to, you'd see the following:
The changes to Quicktime 7 seem to be drastic enough that I'm a little surprised that they were able to get QT7 to work at all on previous versions of OSX, not to mention Windows
Yes, obviously, QT7 has been made available for Panther. The interesting bit is that QT7 seems to depend on APIs that were developed for Tiger -- specifically, CoreVideo (which in turn builds on CoreAudio and CoreImage) and Quartz2d Extreme. With that in mind, getting QT7 to work on Panther must have involved backporting those APIs to the previous version of the operating system.
That, in turn, has me curious if Panther developers can use the QT7 SDK to develop software for Panther that takes advantage of these new libraries, so that people who don't make the jump to Tiger can still use some of the new software that it is going to enable. Chances are, it'll probably be more trouble than it's worth, but the fact will remain that the basic tools were brought back to Panther with QT7, so if someone really wanted to, they could take advantage of them.
For much more excellent detail on Quicktime 7, go read the relevant section of John Siracusa's in-depth Tiger review for Ars Technica. From his description there, Quicktime 7 seems to be a radical & long overdue redesign of Quicktime that wouldn't be possible without some of the architectural changes that OSX 10.4 has delivered, particularly Quartz 2D Extreme and CoreImage. To quote from Siracusa's Quicktime analysis:
Despite the ongoing annoyance of the "QuickTime Pro tax," QuickTime 7 is the most important upgrade to QuickTime in the Mac OS X era. It solves long-standing architectural problems, leverages several of Tiger's other new technologies to do things only dreamt of by QuickTime 6 and earlier, includes its own best-of-breed video codec, and is finally embraced by Cocoa. The new QuickTime Player is good enough to be in danger of reinforcing the (largely uninformed) folk wisdom in the Mac community that rewriting an application in Cocoa automatically makes it better. QuickTime 7 has been a long time in coming, but it has turned out to be well worth the wait.
(And if Apple feels like there's nothing left to do for QuickTime 8 except produce plug-ins for the alphabet soup of audio and video codecs, subtitle tracks, and container formats used by those inscrutable Anime fansubbers, you won't hear me complaining...)
The changes to Quicktime 7 seem to be drastic enough that I'm a little surprised that they were able to get QT7 to work at all on previous versions of OSX, not to mention Windows. Presumably, the new APIs had to be at least partially encapsulated and backported to Panther and will have to be crossported to Windows. That, in turn, has me wondering if it will be possible to use Quicktime to write software on Panther or Windows that takes advantage of these new tools -- probably not, but it's tantalizing.
Anyway, Siracusa's reviews of Panther and previous versions have been consistently excellent, going way more in depth than any other reviews of the system have done. These articles should be considered required reading for anyone that wants to really understand OSX.
With BitKeeper, every repository can be both a clone of one repository -- a client -- and the parent of another repository -- a server. The system is completely distributed, peer-to-peer, whatever you want to call it.
This is not a CVS / SVN workalike where everyone checks things out of and in to a central server instance: the same bk tool can be used to both bk pull changes down from a parent/server and bk push changes back to a clone/client -- and you can do this circularly, so the same two repositories can be both parent and clone of the other.
So what Tridge pointed out can show people what needs to happen to replicate the client-ish aspects of BitKeeper, which would be enough to get BK clients that behave a lot like, say, CVS clients behave. But that's only half of the functionality that the same bk tool is capable of...
Agreed. Delicious Library is a fantastic application that should be able to do a wonderful job with this. Out of the box, it already has support for some of the things that a real, physical, lending library would need:
It maintains a list of assets (books, movies, albums, video games), and will look up as much information about each asset as possible from Amazon's site
Inputting data is fairly easy if you have an iSight camera or their Bluetooth scanner. Once the bard code has been read, everything else happens automatically.
It automatically generates a list of borrowers from your user account's address book, and will allow you to keep track of who is borrowing which asset; likewise, you can look up what assets each borrower is currently holding, including when they borrowed it.
Most of the interesting data exists as XML files under ~/Library/Application Support/Delicious Library, so if the application itself doesn't do what you need, you can hack the XML source to do what you want. For example, if you want to provide a web front end for people, it would be fairly easy to hack up a script that uses XSLT to translate the DL XML data into an HTML site.
Plus, it's a young application from a young company, made by what seems to be a tight & enthusiastic team of people. I bet they'd be deliriously happy to find out that an actual library wanted to use their application -- if you contact them about what you want to do, they might even be able to get features you need into future versions of the software.
It's not open source, but it's damned good software. Give it a try and you may find that it's just what you need to get started...
For the most part, I think you've got it spot-on -- this merger is almost nothing but bad news, in a variety of ways. This part, however, has me curious:
Adobe will "merge" GoLive and Dreamweaver, which will be good for GoLive and bad for Dreamweaver.
How do you figure this? Dreamweaver seems to have a far better reputation among web designers than GoLive ever has, and the user base appears to be many times larger for Dreamweaver.
While I agree that Adobe will probably shut down most of the Macromedia product line, in this case, my hunch was that the Macromedia product will replace the one they had been selling.
How sure do you feel about this? What makes you so sure? With the rest of the Macromedia product line, I think you're spot-on, but in this case, I think Dreamweaver -- along with Flash and maybe ColdFusion -- was [were] the main asset that Adobe was hoping to acquire in the merger, and I don't expect it to go away any time soon.
...but maybe there's something I'm not thinking of here...
Why the decision to go with an almost totally American leading cast)? Other big book to movie adaptations (Harry Potter and Lord of the Rings) did outstanding with a fully british, and very mixed (respectively) cast. Was this by design to win over American audiences, or studio pressure, or just because they were the best auditioned actors these right roles? and also, were they the 1st choice for the roles.
Basically, according to Boyle, there's a checklist of British-isms that are believed to cut into the marketability of a film when it is screened in the USA. The bigger the movie, &/or the more likely the producers intend to bring the movie to the American market, the more closely they need to adhere to this checklist. Every checked-box on the list is a compromise for the director -- a little movie like Boyle's Millions can get away with mostly ignoring it, but a high profile movie like Hitchhiker "has to" pay more attention to the list.
For better or worse, this checklist comes up all the time. Jokes based on references to "zebra crossings" and "Ford Prefect" will be lost on the vast majority of Americans, for example. (And it's not just the Hitchhikers movie: the green smiling mascot familiar to American readers of the books never showed up in the British editions [at least at first, not sure about later ones]; with the Harry Potter books and movies, some of the names & dialog were changed so that they'd be less alien to American kids.)
If the director has a lot of clout, or doesn't care about the American mass market, then they can get away with this, but with something as prominent as Hitchhiker, they'll feel like they "had" to Americanize it, whether or not fans of the original versions of the story agree with sanding down all the quirky bits that made the stories so fun to them in the past.
As have slander, liable, copyright, trademark, military secrets, etc. laws.
In the context of this sentence, I'm pretty sure that should be libel, not liable:
$ dict -d wn libel 1 definition found
From WordNet (r) 2.0 [wn]:
libel n 1: a tort consisting of false and malicious publication printed for the purpose of defaming a living person 2: the written statement of a plaintiff explaining the cause of action (the defammation) and any relief he seeks v : print slanderous statements against; "The newspaper was accused of libeling him" [also: {libelling}, {libelled}] $
YES, by saying "not counting the Unix foundation", I am trying to explicitly make an exception for the older NeXT foundations of OSX.
I'm fully aware of how old the NeXT kit is. But the point is that, aside from a very small pool of developers like Stone Design and Omnigroup, nearly no one used the (admittedly very nice) toolkit that you're talking about. Certainly compared to the userbase of the DOS / Windows kit, it had to be at least a couple of orders of magnitude smaller.
All of this is nice but I really don't see how it sheds any light on the original question of why Apple gives away their tools and Microsoft doesn't (or didn't, considering that apparently a light version of VS is available for free now). I don't see how the age or quality of the NeXT foundation has anything to do with that question. Do you?
:-)
It's not that topic drift is verboten, it's that I keep trying to point how Apples are *ahem* different from Oranges, and you keep pointing out how tasty Apples are.
Which is true and a point worth making in some situations, but in this case it doesn't really seem to further the conversation, you see?
Hence my exasperation:-)
Super. Me too. But what does have to do with my point about why Apple gives away XCode but Microsoft has not given away Visual Studio ? Hm ?
Look -- the superior quality of the NeXT derived toolkit has NOTHING WHATSOEVER DO TO WITH THE BUSINESS DECISION TO GIVE THEM AWAY. NOTHING.
You have, as they say, taken the wrong end of the stick, and gone hurtling over the edge of a cliff with it:-)
I like the NeXT stuff too, but this thread wasn't about software quality. No. It was about the business rationale for charging money for it or not charging money for it. For the most part -- that is to say, entirely -- this has NOTHING to do with which is the higher quality product, and EVERYTHING to do with analysis of the markets that the two vendors work in.
You can repeat how nice the NeXT tools are -- again -- and I'll agree -- again -- but that still won't address the point at hand!:-)
Companies successful w/ NeXTstep (other than the afore-mentioned Omni): [...]
Programs w/ a heavy NeXT heritage: [...]
Oh yeah, and there's this little project called GNUstep....
The operative word there being "little":-)
Look, I'm not trying to disparage the heritage of NeXT. I am fully aware that there was and is a small but tenacious band of prominent developers that loved it, and by proxy, all the people that love working with Cocoa today are, in effect, embracing NeXT as well.
BUT THAT IS NOT THE POINT.
You just rattled off a dozen or so NeXT using companies and individuals. Now, for balance, enumerate the Windows using companies and individuals.
Shall I wait?:-)
The fact is, no matter how talented the small band of NeXT developers were, no matter how much the toolkit helped that small band do widely popular things (like, say, invent the web and first-person shooter video games), they're still the overwhelming minority! Because of this, Apple gives away their tools, but because this doesn't apply on the Windows side, Microsoft does charge for their tools.
Period. Fin. End of over-elaboration of simple point. This still has nothing to do with how nice the NeXT / Cocoa libraries are, and everything to do with user base size. Capice?:-)
>On OSX, the platform -- not counting the Unix foundation -- is young
Are you kidding? Cocoa is based on NeXTStep, which has been actively refined since the late 80's. Win32 dates from the early 90's, and.NET is even younger still.
Ahem. Let me repeat that, with emphasis:
On OSX, the platform --
not counting the Unix foundation -- is young
I'm perfectly aware that the roots of OSX go back a decade before a product from Apple named "OSX" was ever available to the public, but that's not the point. The only people today that have heard of NeXTStep are computer nerds that either had access to such exotic systems back then or, far more likely, have read interesting stories from the small handful of people that had access to such things back in the day.
OSX, on the other hand, as a contemporary, mass-market product, is relatively young. And even if you include both of the NeXT developers that made the transition (Omni, and... I can't think of anybody but Omni, sorry), you're still dealing with a developer pool that is probably one percent of the size of the Windows development base. (Yes, I just pulled that number out of thin air, but I strongly suspect that it's roughly correct.)
The real point -- which splitting hairs about the age of development toolkits that I didn't even mention completely evades -- is that the Windows developers base is orders of magnitudes bigger than the OSX base, even if you include all three of the NeXT guys. This leads each side to starkly different stances which each make sense on their own terms:
Microsoft needs the revenues ("rent", perhaps) more than they need to accumulate more developers, so they can afford to charge for their toolkit.
Apple needs developers more than they need short-term revenue, so they can afford to give away their toolkit. (Moreover, much of their toolkit is GPL stuff like gcc that they didn't even write in the first place, so charging for it would just complicate things and piss off potential developers.)
Consider the points of view of the two camps and their actions make perfect sense.
On Windows, the platform is mature and widely adopted, with a rich variety of software from independent vendors. Microsoft feels they can charge for the development tools, and does so.
On OSX, the platform -- not counting the Unix foundation -- is young, with a comparitively miniscule pool of software vendors. Apple needs to grow the pool of available software for the platform, so giving their development suite away is a way to encourage more software to be available for the platform in the long run, and so to make the platform more viable in the long run. It's a short term expense, but a long term investment.
The motivations on the two sides are different, so of course the approaches are as well.
OSX has many free, high quality development tools
on
Modern Mac Development?
·
· Score: 4, Informative
As a professional Windows developer, what sort of expense am I facing to outfit a new Mac with development tools comparable to Microsoft's Visual Studio.NET, and what sort of learning curve should I expect
Whether or not it's comparable is debatable, but every copy of OSX includes XCode, which is a full suite of graphical and command line development tools: programs, libraries, examples, and copious documentation. And it's free.
So there's that.
Additionally, if you get a copy of Tiger -- which a Mac bought now should either include or be eligible for an upgrade to -- then you get Dashboard, which will let you develop small desktop applications using, as I understand it, Javascript as the development language.
So there's also that.
Additionally, if you get a copy of Tiger, you will get Automator, which is a kind of graphical scripting application that can do all kinds of things. From what I can tell, it is going to be great in all the ways that the appropriately-acronymed AppleScript Studio wasn't.
So there's that, too.
Plus, every version of OSX has supported the full range of Unix shells and scripting languages, so you can write command-line, X11, and sometimes Aqua-based graphical applications using languages such as Perl, Python, Ruby, the Bourne shell, etc.
So to top it all off, there's that.
And to drive the point home, you get all of this for free with every Mac. I've heard nice things about Visual Studio, and maybe there's a lot it can do that the Mac side doesn't have, but I strongly suspect that the full range of programming, scripting, and automation tools available on the Mac will run rings around it without costing you a dime more than the cost of the computer [and OS, if you're upgrading, which you won't be in this case].
I missed a few of the early episodes, so don't really remember this character clearly. But if his name really is Doctor Roberts, and he really is a cylon, then maybe the name has a hint in the lyrics of a Beatles song from "Revolver"...
Doctor Robert
Lennon/McCartney
Lyrics: Ring, my friend I said you'd call Doctor Robert Day or night he'll be there any time at all Doctor Robert
Doctor Robert You're a new and better man He help you to understand He does everything he can Doctor Robert
If you're down he'll pick you up Doctor Robert Take a drink from his special cup Doctor Robert
Doctor Robert He's a man you must believe Helping anyone in need No one can succeed like Doctor Robert
Well, well, well, you're feeling fine Well, well, well, he'll make you Doctor Robert
My friend works for the National Health Doctor Robert Don't pay money just to see yourself Doctor Robert
Doctor Robert You're a new and better man He help you to understand He does everything he can Doctor Robert
Well, well, well, you're feeling fine Well, well, well, he'll make you Doctor Robert
Ring, my friend I said you'd call Doctor Robert Doctor Robert
Sounds like a hint to me -- "new and better man", "does everything he can", "take a drink from his special cup", etc. Fitting phrases for a fake doctor on a mission to influence the president's office...
...surely it can't have anything to do with a collective realization that software themes and skins are a STUPID STUPID STUPID idea, can it?
I mean, okay, maybe DiBona mismanaged the site -- I visited it once or twice, but mainly in horror at the very idea -- but then maybe it deserved to die.
Maybe Google hired him because they figured that scuttling Themes.org was doing the world a favor...
I miss that Slashdot quality assurance thing that used to be. I mean editors seem to publish more and more unuseful things over the time.
Hm? Looking over the oldest Slashdot stories I can find on Google (searching just for timestamps in the url, not for any particular string in the page body), I'm not sure if I agree with that rose-colored past:
Slashdot | New WindowMaker
New WindowMaker -- article related to GNUStep.
slashdot.org/article.pl?sid=98/01/29/172600&tid=94 - 17k - Cached - Similarpages
Slashdot | New E Already Released
New E Already Released -- article related to Enlightenment.
slashdot.org/article.pl?sid=98/01/19/091100&tid=11 5 - 17k - Cached - Similarpages
Slashdot | ePlus DR9 Released
ePlus DR9 Released -- article related to ePlus.
slashdot.org/article.pl?sid=98/01/18/042400&tid=11 9 - 18k - Cached - Similarpages
Slashdot | New E Relase
New E Relase -- article related to Enlightenment.
slashdot.org/article.pl?sid=98/01/18/071301&tid=11 5 - 17k - Cached - Similarpages
Okay, it was the 90s, people were crazy and did foolish things like use Enlightenment and hang on every patch that came out, but come on. Sure, these stores are at least real events rather than future speculation, but they're hardly any more substantial than this article today...
Slashdot can be a fascinating site, but it has never been a beacon of elevated journalistic rigor. I gave up on it becoming such a thing a long, long time ago -- it is what it is, and it's not what it's not. So it goes.
Slashdot Mirror
And this isn't the first time he has come up with some interesting research that has been mentioned on Slashdot before. Sure, he seems to be a little arrogant, but with his record so far, I think he's earned the benefit of the doubt here...
I like how all the other replies get hung up on the throwaway "why is this news" comment, but none draws attention to the brilliant product release schedule suggestion. Why not do something like this? Hm?
I've been browsing Slashdot without the slashboxes for years now, but I'd turn them all back on just to get one that did what you're describing here. Heck, you could even set up different ones for different sections, so the main page would get the cross-platform and most-popular items (Firefox, Linux kernel, OSX release, etc) and the sections would get ones that were appropriate to them (e.g. the Apple one could have versions of Safari, Firefox, Camino, iTunes, OSX, etc; a Windows one (say, why is there no Windows section?) could have recent hotfixes, service packs, etc.
As a bonus, the "last update" item could link to the article about the most recent release, while the "product" link can link to a search for all the release articles for that product. And with everything bundled up there, the release articles could be moved off the front page and we'd get less of this whining about new releases not being newsworthy events.
I don't suppose there's any chance that this could be implemented, could it?
I guess they're just not that worried in investing the 59 seconds it would take to placate both of the world's Ogg users.
I can't blame them, really. They seem to be doing pretty well so far by ignoring these Ogg fanatics (both of which, aside from incessant Slashdot whining, don't ever actually seem to show up in real life).
But YMObviouslyVaries... :-)
Not to nitpick, but wouldn't the computer with a "one" in the name be more usefully thought of as the one that started it all ?
And that's not even getting into earlier computers that can be thought of as having started it all (EVIAC anyone?) or proto-computers (*ahem* Babbage's Difference and Analytical Engines) or proto-proto-computers (the Jacquard loom, the abacus, etc), or more broadly, the things that *really* started it all (the Big Bang, the original monocellular organisms, or for the people in Kansas, pick your fairy tale of choice).
Maybe we should have clarified what "it" is that was "all started". But it's too late now...
No, it isn't. This is a crude, crude simulation of what SEE allows people to do cleanly, painlessly, and transparently. As noted in one of the URLs I linked to previously, screen is not equivalent to what SubEthaEdit is doing, because unlike pretty much every other editor ever, SubEthaEdit supports multiple concurrent insertion points.
Yes, you can use screen to share a Vim or Emacs session among multiple people, but they're all still going to have to haggle over who gets to type at any one time. With SEE, on the other hand, everyone can work independently, in the same or in different regions of the same file, and everyone is always looking at the current, collaboratively written version of the same document. To keep things from getting confusing, all the edits I make will have a white background, and all the edits you make will have a pale green background, and all the edits that another person makes will have a sky blue background, and so on and so forth. And this is independent of syntax highlighting, so you also get nicely multicolored text over these multicolored backgrounds.
This is, in short, light years ahead of anything that you could cobble together with Emacs or Vi in a screen session.
By way of comparison, consider VNC. You can share a VNC session such that the console user and one or more observers are sharing the mouse pointer and keyboard input, but you still only get one mouse cursor and one flow of keyboard input, so if I pull left and you pull right, the competition for the cursor cancels out and the pointer ends up somewhere in the middle. With the SEE protocol, by contrast, it's as if every participant gets their own mouse and keyboard, so I can open & work in windows in one corner of the screen, and you can do similar work in another, and if we want, we can work on each other's regions of the screen. (And yes, this would require a bit of cooperation to avoid chaos, but maybe the cursors would be visible on all shared displays, with flags by each cursor to highlight who is working where, so that you could understand at a glance what's going on.)
Spend 30 seconds collaborating with SEE, and you'll realize what a cruel joke of a collaboration method screen-shared Vi/Emacs is...
Moreover, they've written several times that SubEthaEdit leverages several OSX technologies, including both Bonjour and Cocoa, as well as makes (unorthodox?) use of open protcols like BEEP. From the sound of it, getting SEE to work without this toolkit would be very hard to do.
I'm a little more interested in support for the SEE protocol in an editor like Vim or Emacs. If they can add it, then it'll instantly be available to people using any platform at all, even if SEE never gets ported to anything else. From what I can tell, this is a lot more likely, but so far I haven't heard of anyone working on hacking up these editors to support SEE style collaborative editing. Oh well...
Well, it's sort of an OS issue, and it's sort of an application issue.
The support for automatic resource discovery should be provided by the operating system, yes, but applications need to integrate this in appropriate ways. Web browsers, for example, need to actually ask for that information, and need to provide an interface for accessing it.
It doesn't really have anything to do with IE's file managing capabilities. With the new version of Bonjour for Windows, Apple has provided a plugin that allows IE users to browse local Rendezvous^W Bonjour HTTP resources from directly in the browser, via both a toolbar icon and a menu option, both of which open up an Explorer Bar panel on the left side of the browser window -- similar to the standard history / media / folders / etc views -- that shows a list of current Rendezvous^H^H^H Bonjour advertised URLs. While the OS, by way of the Bonjour subsystem, is providing the mechanism for finding these resources, the plugin for IE is a separate component that exploits that subsystem from within IE. You need both halves to do anything useful with this.
And boy is this ever useful. At my job, I'm already using the mod_rendezvous_apple^W mod_bonjour Apache module to advertise a list of URLs for things useful to all the staff here -- the phone book, the intranet search engine, the bug tracker, the documentation wiki, etc -- so that all the users of Bonjour capable browsers automatically get a shared bookmark list. So far, this has only been useful for the people using OSX and Safari or Camino, but now it'll be useful to the people using IE on Windows. This would be great, were it not for the fact that we've managed to migrate almost all the Windows users over to Firefox by now. What would be really useful would be for Apple to bundle a Firefox plugin, or for Mozdev or someone to provide one that takes advantage of the Bonjour for Windows [and Linux!] API. If that became available, then everyone would be able to benefit from these automatically advertised resources.
The next step might be to come up with a CUPS/Bonjour bridge, so that the Windows users can automatically discover the CUPS printers in the same way that the OSX and Linux users can. I assume it should be possible...
But "very clean", apparently, wasn't good enough. Now, launchd replaces this entire approach, along with a whole bunch of other traditional Unix cruft. It's actually a radical rethinking of how all these things have been done by every Unix vendor for the last 30 years, and from the looks of it, it's a huge step forward.
I'll be very disappointed if other systems don't pick this up.
Yes, and if you'd read the entire post that you're replying to, you'd see the following:
Yes, obviously, QT7 has been made available for Panther. The interesting bit is that QT7 seems to depend on APIs that were developed for Tiger -- specifically, CoreVideo (which in turn builds on CoreAudio and CoreImage) and Quartz2d Extreme. With that in mind, getting QT7 to work on Panther must have involved backporting those APIs to the previous version of the operating system.
That, in turn, has me curious if Panther developers can use the QT7 SDK to develop software for Panther that takes advantage of these new libraries, so that people who don't make the jump to Tiger can still use some of the new software that it is going to enable. Chances are, it'll probably be more trouble than it's worth, but the fact will remain that the basic tools were brought back to Panther with QT7, so if someone really wanted to, they could take advantage of them.
For much more excellent detail on Quicktime 7, go read the relevant section of John Siracusa's in-depth Tiger review for Ars Technica. From his description there, Quicktime 7 seems to be a radical & long overdue redesign of Quicktime that wouldn't be possible without some of the architectural changes that OSX 10.4 has delivered, particularly Quartz 2D Extreme and CoreImage. To quote from Siracusa's Quicktime analysis:
The changes to Quicktime 7 seem to be drastic enough that I'm a little surprised that they were able to get QT7 to work at all on previous versions of OSX, not to mention Windows. Presumably, the new APIs had to be at least partially encapsulated and backported to Panther and will have to be crossported to Windows. That, in turn, has me wondering if it will be possible to use Quicktime to write software on Panther or Windows that takes advantage of these new tools -- probably not, but it's tantalizing.
Anyway, Siracusa's reviews of Panther and previous versions have been consistently excellent, going way more in depth than any other reviews of the system have done. These articles should be considered required reading for anyone that wants to really understand OSX.
With BitKeeper, every repository can be both a clone of one repository -- a client -- and the parent of another repository -- a server. The system is completely distributed, peer-to-peer, whatever you want to call it.
This is not a CVS / SVN workalike where everyone checks things out of and in to a central server instance: the same bk tool can be used to both bk pull changes down from a parent/server and bk push changes back to a clone/client -- and you can do this circularly, so the same two repositories can be both parent and clone of the other.
So what Tridge pointed out can show people what needs to happen to replicate the client-ish aspects of BitKeeper, which would be enough to get BK clients that behave a lot like, say, CVS clients behave. But that's only half of the functionality that the same bk tool is capable of...
Agreed. Delicious Library is a fantastic application that should be able to do a wonderful job with this. Out of the box, it already has support for some of the things that a real, physical, lending library would need:
Etc.
Plus, it's a young application from a young company, made by what seems to be a tight & enthusiastic team of people. I bet they'd be deliriously happy to find out that an actual library wanted to use their application -- if you contact them about what you want to do, they might even be able to get features you need into future versions of the software.
It's not open source, but it's damned good software. Give it a try and you may find that it's just what you need to get started...
For the most part, I think you've got it spot-on -- this merger is almost nothing but bad news, in a variety of ways. This part, however, has me curious:
How do you figure this? Dreamweaver seems to have a far better reputation among web designers than GoLive ever has, and the user base appears to be many times larger for Dreamweaver.
While I agree that Adobe will probably shut down most of the Macromedia product line, in this case, my hunch was that the Macromedia product will replace the one they had been selling.
How sure do you feel about this? What makes you so sure? With the rest of the Macromedia product line, I think you're spot-on, but in this case, I think Dreamweaver -- along with Flash and maybe ColdFusion -- was [were] the main asset that Adobe was hoping to acquire in the merger, and I don't expect it to go away any time soon.
...but maybe there's something I'm not thinking of here...
In an interview on The Connection on WBUR radio this week, Danny Boyle -- indie director of "Trainspotting" and other movies -- commented on this very point.
Basically, according to Boyle, there's a checklist of British-isms that are believed to cut into the marketability of a film when it is screened in the USA. The bigger the movie, &/or the more likely the producers intend to bring the movie to the American market, the more closely they need to adhere to this checklist. Every checked-box on the list is a compromise for the director -- a little movie like Boyle's Millions can get away with mostly ignoring it, but a high profile movie like Hitchhiker "has to" pay more attention to the list.
For better or worse, this checklist comes up all the time. Jokes based on references to "zebra crossings" and "Ford Prefect" will be lost on the vast majority of Americans, for example. (And it's not just the Hitchhikers movie: the green smiling mascot familiar to American readers of the books never showed up in the British editions [at least at first, not sure about later ones]; with the Harry Potter books and movies, some of the names & dialog were changed so that they'd be less alien to American kids.)
If the director has a lot of clout, or doesn't care about the American mass market, then they can get away with this, but with something as prominent as Hitchhiker, they'll feel like they "had" to Americanize it, whether or not fans of the original versions of the story agree with sanding down all the quirky bits that made the stories so fun to them in the past.
"Burn Hollywood, burn."
In the context of this sentence, I'm pretty sure that should be libel, not liable:
Hope this helps... :-)
Please read the rest of the thread before splitting hairs here.
YES, by saying "not counting the Unix foundation", I am trying to explicitly make an exception for the older NeXT foundations of OSX.
I'm fully aware of how old the NeXT kit is. But the point is that, aside from a very small pool of developers like Stone Design and Omnigroup, nearly no one used the (admittedly very nice) toolkit that you're talking about. Certainly compared to the userbase of the DOS / Windows kit, it had to be at least a couple of orders of magnitude smaller.
All of this is nice but I really don't see how it sheds any light on the original question of why Apple gives away their tools and Microsoft doesn't (or didn't, considering that apparently a light version of VS is available for free now). I don't see how the age or quality of the NeXT foundation has anything to do with that question. Do you?
:-) It's not that topic drift is verboten, it's that I keep trying to point how Apples are *ahem* different from Oranges, and you keep pointing out how tasty Apples are. Which is true and a point worth making in some situations, but in this case it doesn't really seem to further the conversation, you see? Hence my exasperation :-)
Super. Me too. But what does have to do with my point about why Apple gives away XCode but Microsoft has not given away Visual Studio ? Hm ?
Look -- the superior quality of the NeXT derived toolkit has NOTHING WHATSOEVER DO TO WITH THE BUSINESS DECISION TO GIVE THEM AWAY. NOTHING.
You have, as they say, taken the wrong end of the stick, and gone hurtling over the edge of a cliff with it :-)
I like the NeXT stuff too, but this thread wasn't about software quality. No. It was about the business rationale for charging money for it or not charging money for it. For the most part -- that is to say, entirely -- this has NOTHING to do with which is the higher quality product, and EVERYTHING to do with analysis of the markets that the two vendors work in.
You can repeat how nice the NeXT tools are -- again -- and I'll agree -- again -- but that still won't address the point at hand! :-)
The operative word there being "little" :-)
Look, I'm not trying to disparage the heritage of NeXT. I am fully aware that there was and is a small but tenacious band of prominent developers that loved it, and by proxy, all the people that love working with Cocoa today are, in effect, embracing NeXT as well.
BUT THAT IS NOT THE POINT.
You just rattled off a dozen or so NeXT using companies and individuals. Now, for balance, enumerate the Windows using companies and individuals.
Shall I wait? :-)
The fact is, no matter how talented the small band of NeXT developers were, no matter how much the toolkit helped that small band do widely popular things (like, say, invent the web and first-person shooter video games), they're still the overwhelming minority! Because of this, Apple gives away their tools, but because this doesn't apply on the Windows side, Microsoft does charge for their tools.
Period. Fin. End of over-elaboration of simple point. This still has nothing to do with how nice the NeXT / Cocoa libraries are, and everything to do with user base size. Capice? :-)
Ahem. Let me repeat that, with emphasis:
I'm perfectly aware that the roots of OSX go back a decade before a product from Apple named "OSX" was ever available to the public, but that's not the point. The only people today that have heard of NeXTStep are computer nerds that either had access to such exotic systems back then or, far more likely, have read interesting stories from the small handful of people that had access to such things back in the day.
OSX, on the other hand, as a contemporary, mass-market product, is relatively young. And even if you include both of the NeXT developers that made the transition (Omni, and... I can't think of anybody but Omni, sorry), you're still dealing with a developer pool that is probably one percent of the size of the Windows development base. (Yes, I just pulled that number out of thin air, but I strongly suspect that it's roughly correct.)
The real point -- which splitting hairs about the age of development toolkits that I didn't even mention completely evades -- is that the Windows developers base is orders of magnitudes bigger than the OSX base, even if you include all three of the NeXT guys. This leads each side to starkly different stances which each make sense on their own terms:
Consider the points of view of the two camps and their actions make perfect sense.
I don't think that's the reasoning at work here.
On Windows, the platform is mature and widely adopted, with a rich variety of software from independent vendors. Microsoft feels they can charge for the development tools, and does so.
On OSX, the platform -- not counting the Unix foundation -- is young, with a comparitively miniscule pool of software vendors. Apple needs to grow the pool of available software for the platform, so giving their development suite away is a way to encourage more software to be available for the platform in the long run, and so to make the platform more viable in the long run. It's a short term expense, but a long term investment.
The motivations on the two sides are different, so of course the approaches are as well.
Whether or not it's comparable is debatable, but every copy of OSX includes XCode, which is a full suite of graphical and command line development tools: programs, libraries, examples, and copious documentation. And it's free.
So there's that.
Additionally, if you get a copy of Tiger -- which a Mac bought now should either include or be eligible for an upgrade to -- then you get Dashboard, which will let you develop small desktop applications using, as I understand it, Javascript as the development language.
So there's also that.
Additionally, if you get a copy of Tiger, you will get Automator, which is a kind of graphical scripting application that can do all kinds of things. From what I can tell, it is going to be great in all the ways that the appropriately-acronymed AppleScript Studio wasn't.
So there's that, too.
Plus, every version of OSX has supported the full range of Unix shells and scripting languages, so you can write command-line, X11, and sometimes Aqua-based graphical applications using languages such as Perl, Python, Ruby, the Bourne shell, etc.
So to top it all off, there's that.
And to drive the point home, you get all of this for free with every Mac. I've heard nice things about Visual Studio, and maybe there's a lot it can do that the Mac side doesn't have, but I strongly suspect that the full range of programming, scripting, and automation tools available on the Mac will run rings around it without costing you a dime more than the cost of the computer [and OS, if you're upgrading, which you won't be in this case].
I missed a few of the early episodes, so don't really remember this character clearly. But if his name really is Doctor Roberts, and he really is a cylon, then maybe the name has a hint in the lyrics of a Beatles song from "Revolver"...
Sounds like a hint to me -- "new and better man", "does everything he can", "take a drink from his special cup", etc. Fitting phrases for a fake doctor on a mission to influence the president's office...
...surely it can't have anything to do with a collective realization that software themes and skins are a STUPID STUPID STUPID idea, can it?
I mean, okay, maybe DiBona mismanaged the site -- I visited it once or twice, but mainly in horror at the very idea -- but then maybe it deserved to die.
Maybe Google hired him because they figured that scuttling Themes.org was doing the world a favor...
Hm? Looking over the oldest Slashdot stories I can find on Google (searching just for timestamps in the url, not for any particular string in the page body), I'm not sure if I agree with that rose-colored past:
Enlightenment Themes Vote -- article related to Enlightenment.
slashdot.org/article.pl?sid=98/01/27/224500&tid=1
New WindowMaker -- article related to GNUStep.
slashdot.org/article.pl?sid=98/01/29/172600&tid=9
New E Already Released -- article related to Enlightenment.
slashdot.org/article.pl?sid=98/01/19/091100&tid=1
ePlus DR9 Released -- article related to ePlus.
slashdot.org/article.pl?sid=98/01/18/042400&tid=1
New E Relase -- article related to Enlightenment.
slashdot.org/article.pl?sid=98/01/18/071301&tid=1
Okay, it was the 90s, people were crazy and did foolish things like use Enlightenment and hang on every patch that came out, but come on. Sure, these stores are at least real events rather than future speculation, but they're hardly any more substantial than this article today...
Slashdot can be a fascinating site, but it has never been a beacon of elevated journalistic rigor. I gave up on it becoming such a thing a long, long time ago -- it is what it is, and it's not what it's not. So it goes.