Slashdot Mirror

← Back to Domains

Domain: arstechnica.com

Stories and comments across the archive that link to arstechnica.com.

Comments · 9,494

  1. Re:JIT != compiler by barracg8 · · Score: 1 · on C# Under The Microscope
    On the whole JIT vs static compiling issue, I'd like to point out HP's Dynamo (I own credit for this link to toh, from a recent post on askslashdot). Anyway, what HP are doing, is a VM like Sun's hotspot, initially interpreting code, then JIT compiling it. The interesting thing, is it compiles from HP-PA to HP-PA. :-) The idea is to optomize the most commonly used bits of code, while the program is running.

    The JIT gives a 10%-15% speed increase over running the code without the VM.

    You make a very valid point, that running Java on Windows can be a pain (or rather, getting it installed in the first place).

    But this may improve, due to the DOJ / Microsoft trial. The appeals may delay the split for years, but as I understand it, some of the controls kick in within the the next two months. I think, MS will be stopped from restricting what software (read: Netscape) may be installed on PCs when they are shipped. This may mean companies start selling PCs supporting Java out the box. MacOS X supporting Java2 out the box may help encourage PC manufacturers in the right direction :-)

  2. Objective-C, NeXTStep, OpenStep, Mac OS X, and C# by plsuh · · Score: 5 · on C# Under The Microscope
    It is useful to note that much of what C# provides actually originated in the context of NeXT, the Objective-C language, and the associated operating systems.

    Inheritance and Interfaces

    Another idea that was lifted directly off Java, and one which turned out to be very controversial is that of multiple inheritance. In what seemed like a step backwards, Java did not allow you to define classes that inherit from one than one class. Java did let you define "interfaces", which work like C++ abstract classes, but were semantically clearer: an interface is a functional contract that declares one or more methods.
    Objective-C in the OpenStep/Mac OS X environment has single inheritance from a base class (NSObject), and protocols, which are precise counterparts to Java's interfaces. I have run into situations, however, where multiple inheritance is exactly what is required, and using interfaces meant that I had re-write the exact same code more than once, as I was implementing a group of specialized collection classes in Java. There were two axes of differentiation: mutability = (immutable, mutable), and ordering (partially ordered, ordered, strictly ordered). There was a lot of code that had to be duplicated that I should have been able to inherit from two abstract superclasses, one for mutability, and one for ordering. (*grumble*)

    Garbage Collection and Memory Management

    One new feature that I mentioned already was that of copy-by-value objects. This seemingly small improvement is a potentially huge performance saver! With C++, one is regularly tempted to describe the simplest constructs as classes, and in so doing make it safer and simpler to use them. For example, a phone directory program might define a phone record as a class, and would maintain one PhoneRecord object per actual record. In Java, each and every one of those objects would be garbage collected! Now, Java uses mark-and-sweep in order to garbage collect. The way that this is done is this: the JVM starts with the program's main object, and starts recursively descending through references to other objects. Every object that is traversed is marked as referenced. When this is done, all of the objects that aren't marked are destroyed. In the phone book program, especially if there are thousands and thousands of phone records, this can drastically increase the time that it takes the JVM to go through the marking phase. In C#, you'd be able to avoid all this by defining PhoneRecord as a struct instead of a class.
    Objective-C provides a semi-automatic reference-counted garbage collection mechanism that is amenable to programmer intervention to increase efficiency, through a construct called an Autorelease Pool. Every object has a retain count, which can be incremented or decremented. The object's retain count starts at one, and when an object's retain count goes down to zero it is garbage collected. Note that this happens the instant that the retain count drops to zero, not during a mark/sweep. However, you may need to pass an object on to another part of your app, but your code does not need/want to retain it. What you do instead is tell the object to auto-release. It is then put into the autorelease pool, and later on during the system's garbage collection each object in the autorelease pool is sent a release message. Some objects that are entered in the autorelease pool still have a retain count (as they are being retained by other objects) and are simply removed from the autorelease pool; others have their retain counts drop to zero and are garbage collected.

    You can fine-tune this mechanism to a high degree, by putting your own autorelease pool in the stack ahead of the system's primary autorelease pool. For instance, suppose you know that you will be allocating a whole bunch of objects for use in a part of your program, and after you exit you will never need them again. Well, you can put your own autorelease pool in for the system's autorelease pool at the start of that section of your code, write normal code, then remove and release your private autorelease pool and put back the system autorelease pool, which release all of the objects you created in your little section of code. Conversely, if you want an object to stick around, just don't ever release or autorelease it.

    However, from a business standpoint, I find that the automated garbage collection and never having to worry about memory allocation issues is a strong point of Java. It allows me to code more complex applications and avoid memory debugging issues that invarable bedevil complex Objective-C and C++ programs. I can get a WebObjects application to a customer much more quickly using Java than using Objective-C, with quicker turnaround and more feedback cycles.

    Events, Notifications, and Delegation

    Personally, I found C# support of events to be a very exciting new feature! Whereas an object method operates the object in a certain way, object events let the object notify the outside world of particular changes in its state.. A Socket class, for instance, might define a ReadPossible event or a data object might release a DataChanged event. Other objects may then subscribe for such an event so that they'd be able to do some work when the event is released. Events may very well be considered to be "reverse- functions", in the sense that rather than operate the object, they allow the object to operate the outside world, and in my programming experience, events are almost as important as methods themselves.
    The OpenStep and Mac OS X operating systems (viewed separately from the Objective-C language, as these features are available from Java as well) have long had notifications and delegates. There is a system-wide notification center, objects can define notifications that they will post in response to certain events, and objects can register to receive particular events or classes of events. This mechanism has been in place for a long time.

    Delegation is a bit more tightly tied to Objective-C, as objects in Obj-C can pass messages (i.e. method calls) onto to other objects, and objects can "pose as" other objects. An object can register to be the delegate of another object (in Java, the delegator object needs to make special provision for this), and there are "informal protocols" or "informal interfaces" defined that indicate the possible messages a delegate might receive from its delegator. Again, this is not new, and its assembly into a single OS is not new.

    Primitive Types

    C# classes are also all eventual descendents of the object class, but unlike Java, primitives such as integers, booleans and floating-point types are considered to be regular classes.
    This is one feature that I like very much, and wish that Java had. Objective-C, of course, will always have to support native types such as char's and int's, as it is defined as a superset of C. However, Java had the opportunity to remove this artificial distinction, and has caused lots of cursing from yours truly over the past couple of years.

    Compiling to Native Code

    It's not yet clear whether C# programs would need the equivalent of a Java Virtual Machine or whether they could be compiled directly into standalone executables, which might positively affect C#'s performance and possibly even set it as a viable successor to C++, at the very least on Windows.
    I would point out here that compiling to native code may not result in the fastest execution. Review the HP Dynamo project, as written up on Ars Technica, for the reasons why JITC can actually exceed the speed of native code. The whole Transmeta Crusoe architecture is built around this theory of operation, and no one will claim that it's too slow.

    Genericity

    One thing that's sure to be missing from C#, and very sadly at that is any form of genericity.
    Amen to this. The fact that genericity is missing from Java is a serious gripe of mine, and the fact that it is missing from C# is a serious omission. This business of casting objects coming out of arrays is a pain the in neck, and it is often tough to find out where an object of the wrong type went into an array, although on the cast coming out you get a ClassCastException. Far better to catch the problem when the object goes in, which often gives you a better idea of where your design is broken. One of these days I am really going to have to start using the stuff coming out of the GJ project.


    Conclusions

    Overall, I find that the "new" stuff in C# is really old stuff. Furthermore, this is not the first time that all of this has been pulled together in one place. Almost all of this has been in the NeXTStep/OpenStep/Mac OS X family for a long time, and the implementations there are quite mature. I suspect that the implementations in C# will require several revisions before they reach the levels that programmers can really use.

    Just so everyone knows, I am a Consulting Engineer working for Apple iServices, a part of Apple Computer, specializing in WebObjects development. These opinions are my own, however, and not those of Apple.


    --Paul
  3. Re:It depends a LOT on hardware by toh · · Score: 2 · on What Is The Future Of Programming Languages?

    The difference between a RISC/CISC processor and a VLIW processor is the fact that RISC/CISC processors have a decoder on the front end for an outdated instruction set. we should buffer against the changing requirment the hardware has of the instruction set, by a adopting a 3 tier approach to execution - in the same way that databases buffer against change in the way data is stored. That means a intermediate, step, such as bytecode.
    Yes. I've felt for a while that a future direction will be CPUs designed to run some intermediate bytecode that's explicitly designed for runtime optimisation. If you look at what HP is doing with Dynamo (which dynamically recompiles HP-PA instructions back into HP-PA instructions before execution by the hardware, typically gaining 10-15% execution speed), it's clear that a split static/dynamic compilation scheme is a win - there are simply too many things in a modern superscalar design that can't be known at static compile time, and thus need to be put off until runtime, a sort of "lazy compilation". One can only imagine that it'd be a bigger win if instead of originally compiling to some legacy instruction set architecture (like HP-PA, PPC, or the old groaning x86), code was first compiled to a bytecode architecture that was specifically designed to mesh with a final dynamic compilation implemented in microcode (or even pure hardware, though I imagine acting on the amount of metainfo needed to do this well would make the design too complex for that).

    When (hopefully not if) someone does pursue this idea, it's reasonable to postulate that some programming languages or even paradigms might be better suited than others to the first-stage static compilation to bytecode. So I guess that's what my own answer to "what is the future of programming languages" depends on. One thing I'll say is that I'm not sure it's Java, which means Sun's MAJC design for the purposes outlined above.

    There's another nice article (companion to the one linked above) at Ars Technica that talks about some of this, though it actually ends up being a sort of review of CPU evolution from hardware lock-in though ISAs through microcode emulation of ISAs. It doesn't really talk about a bytecode-oriented-CPU, but it sure seems a natural next step to me. It's an idea in many ways similar to Crusoe or even (shudder) EPIC, but doing things at different times and in different places.

  4. Re:It depends a LOT on hardware by toh · · Score: 2 · on What Is The Future Of Programming Languages?

    The difference between a RISC/CISC processor and a VLIW processor is the fact that RISC/CISC processors have a decoder on the front end for an outdated instruction set. we should buffer against the changing requirment the hardware has of the instruction set, by a adopting a 3 tier approach to execution - in the same way that databases buffer against change in the way data is stored. That means a intermediate, step, such as bytecode.
    Yes. I've felt for a while that a future direction will be CPUs designed to run some intermediate bytecode that's explicitly designed for runtime optimisation. If you look at what HP is doing with Dynamo (which dynamically recompiles HP-PA instructions back into HP-PA instructions before execution by the hardware, typically gaining 10-15% execution speed), it's clear that a split static/dynamic compilation scheme is a win - there are simply too many things in a modern superscalar design that can't be known at static compile time, and thus need to be put off until runtime, a sort of "lazy compilation". One can only imagine that it'd be a bigger win if instead of originally compiling to some legacy instruction set architecture (like HP-PA, PPC, or the old groaning x86), code was first compiled to a bytecode architecture that was specifically designed to mesh with a final dynamic compilation implemented in microcode (or even pure hardware, though I imagine acting on the amount of metainfo needed to do this well would make the design too complex for that).

    When (hopefully not if) someone does pursue this idea, it's reasonable to postulate that some programming languages or even paradigms might be better suited than others to the first-stage static compilation to bytecode. So I guess that's what my own answer to "what is the future of programming languages" depends on. One thing I'll say is that I'm not sure it's Java, which means Sun's MAJC design for the purposes outlined above.

    There's another nice article (companion to the one linked above) at Ars Technica that talks about some of this, though it actually ends up being a sort of review of CPU evolution from hardware lock-in though ISAs through microcode emulation of ISAs. It doesn't really talk about a bytecode-oriented-CPU, but it sure seems a natural next step to me. It's an idea in many ways similar to Crusoe or even (shudder) EPIC, but doing things at different times and in different places.

  5. Re:Quote... by benwb · · Score: 2 · on Amiga Update: When Will The Creature Awaken?

    5 years ago sure. But that's becoming less and less true. Hp has a research system called Dynamo that does this. Code run through dynamo runs faster than code natively optimized. Granted dynamo is a research system, and transforms PA-8000 binary code into PA-8000 binary code, but the techniques they used in principle could transform an arbitrary instruction set into another one. Ars Technica has a good article with some performance numbers here.

  6. Switching things around. by B'Trey · · Score: 5 · on Amiga Update: When Will The Creature Awaken?

    Ars Technica posted this as well. Hannibal had an interesting comment: So they're not requiring that all AmigaOS software and tools be written to the virtual processor, which is interesting because this at first seemed to me to be a sort of fence sitting approach that would reduce the advantages of translation -- why not just go ahead and use an OS that's completely portable at the source code level, like Linux? When I thought about, though, I realized that what Amiga wants is to release an OS in binary form that runs on a variety of platforms from the start, and have people start moving pieces of the OS into native binary form for their specific platform as they see fit. This would be the opposite of a Linux-style approach, where you initially release an OS in source code form that runs on one platform, and then let people port the entire thing to their individual hardware.

  7. Raid descriptions by u02sgb · · Score: 1 · on High Sustained HD Transfer Rates on a Budget?
    Possibly slightly offtopic but there's a great article explaining different RAIDs on arstechnica here

    Remember all RAIDs are not created equal.

  8. Re:The real problem by StarKruzr · · Score: 1 · on Hotmail about to collapse under load

    OK I'm sorry. Somebody PLEASE explain this bullshit to me.

    If you were going to troll, couldn't you troll like a normal little horned creature? What is this guy trying to accomplish? He's posting as AC so he's not going to accumulate negative karma. Everything he says is irrelevant, bizarre blustering.

    In case he's actually SERIOUS:

    IT'S A NEWS SITE. JUST a news site, with a comment system for those who think they might have something to say about the news. Like my beloved Ars Technica. Go there if you want a higher signal to noise ratio, K?

    Thank you.

    4920616D206E6F7420656C6974652E
    Email me.

  9. Same optical gear in Intellimouse & new Apple one by bonespsk · · Score: 1 · on Review Of The New Apple Mouse
    According to this article at ArsTechnica, both the Microsoft Intellimouse explorer and the new Apple mouse have the same "tracking mechanism". Read more at http://arstechnica.co m/wankerdesk/3q00/macworld2k/mwny-2.html

    On a personal note, I think if Apple had only put a couple of more buttons on and a scroll wheel, I probably would have forsaken my Intellimouse Explorer to get one. While the functionality is still there with a one-button mouse (you have always been able to use keyboard modifiers: Ctrl-, Shift-, Command-, Option-), it's not as convenient. Plus that scroll wheel, and the ability to map macros to buttons is a huge plus in the Intellimouse.

    <wishful thinking>When's there gonna be an apple-branded multi-button mouse?</wishful thinking>

  10. Re:Problems... by gerti · · Score: 1 · on Why Port from UNIX to OS X?
    If it turns out apps can be ported from OSX to *nix rather easily, then my bet is on M$ not writing any software for OSX.

    I'm not worried about developers writing for *nix and not for OS X.

    M$ already has IE 5 shipping with the latest developer preview of OS X, and they will release Office: from what I heard, they're not just porting it from the current MacOS port, they're redoing it in Cocoa, the NeXTStep based (and most kick-ass of all) OS X API.

    Other popular software will also be available for OS X, as http://www.apple.com/macosx/apps.html shows. Adobe, Microsoft, ID, Quark and others are listed on that page. Because publishing too much OS X info, particularly screenshots, is not yet possible because of non-disclosure agreements, the software companies will wait until the release of the public beta of OS X in september before they start releasing their OS X based beta's. However, pages like Version Tracker (with a MacOS background) and Softrak (with a NeXT background) already list a fair amount of OS X software, ready to download.

    My bet is that there will be a large amount of software for OS X, and there are (at least) four reasons why:

    • As noted in earlier, OS X will have a large userbase: eventually, practically all Mac owners will have a Mac that runs OS X. The Mac userbase is small compared to the windoze victims, but it's larger than the current *n[iu]x community. And it'll grow because people who want a reasonably priced unix-like system with a good GUI will get an OS X box.
    • Apple has done a great job by implementing the Carbon API: the Carbon libraries contain almost all old Mac OS toolbox calls, so most current Mac OS applications will recompile under OS X without a great deal of trouble. And carbon apps will benefit from the new memory manager, scheduler, and user interface. See http://www.xappeal.org/carbon/index.shtml for a list of software that is or will be available in carbonized form.
    • To ease migration to the new OS for old Mac users, Apple created a classic compatibility mode: basicly an application that emulates a Mac running OS 9. It runs all old and non-carbon applications, at roughly 80-90% of the speed it would have if run natively. These apps have the old OS's interface and will crash as often as they did on the old OS, but they won't take the rest of the system down with it.
    • Apple is putting a lot of work in making OS X usable for non-techy consumers: the average granny should feel happy using an OS X Mac. Everything configurable will have to be configurable by GUI-tools, in fact, the Terminal application won't be installed by default. I doubt it's possible to install and configure a usable other *n[iu]x system without ever editing a config file directly. Developers of consumer products like word processors, mail applications, webbrowsers, audio- and video editing software will like the stability and consumer-orientedness of OS X.

    For some excellent technical info on the upcoming OS X, take a look at the reviews Ars Technica did here.

    gerti

    --
    "To invent, you need a good imagination and a pile of junk" - Thomas Edison
  11. Read about a similar idea before. by GeekDork · · Score: 1 · on IETF To Develop Anti-DoS ICMP
    Some time ago, someone at Ars Technica posted a similar idea. I didn't find the artice anymore, but if you have some free time, try and find it as it was very interesting.

    Paranoids of the world, unite!

  12. Why the EE is good for this stuff by ToLu+the+Happy+Furby · · Score: 2 · on Sony Announces GScube Development System

    One of these links has already been posted above, but if anyone wants a well-written, easy-to-understand-but-plenty-technical introduction to why the Emotion Engine is cheap to produce and a terrible general-purpose chip, but an amazing design for high-quality low-latency 3D graphics, assuming programers can figure out how to take advantage of it...

    start with these excellent articles from ArsTechnica:

    Emotion Engine overview

    Comparison of the EE's rendering process to that of a typical PC + graphics card

    The second article is, IMO, the particularly interesting and relevant one, since the approach to rendering taken by today's high end graphics workstations from SGI et. al. is more similar to the PC + graphics card way of doing it than the EE way of doing it. Or rather, the PC + graphics card way of doing it was copied from the workstation approach. Of course, the major problem spot of the PC + card approach to rendering--the horrible bandwidth from the motherboard to the graphics card (the AGP bus is a joke compared to what would be required to actually stream textures into the graphics card in real-time; as it is now, entire levels must be loaded into the graphics card memory and stay there until the next level is accessed)--is not such a problem on a high-end workstation. It'll be quite interesting to see how this GScube thing compares, but the specs are there for it to make a very inexpensive and powerful alternative to the standard SGI stuff.

  13. Why the EE is good for this stuff by ToLu+the+Happy+Furby · · Score: 2 · on Sony Announces GScube Development System

    One of these links has already been posted above, but if anyone wants a well-written, easy-to-understand-but-plenty-technical introduction to why the Emotion Engine is cheap to produce and a terrible general-purpose chip, but an amazing design for high-quality low-latency 3D graphics, assuming programers can figure out how to take advantage of it...

    start with these excellent articles from ArsTechnica:

    Emotion Engine overview

    Comparison of the EE's rendering process to that of a typical PC + graphics card

    The second article is, IMO, the particularly interesting and relevant one, since the approach to rendering taken by today's high end graphics workstations from SGI et. al. is more similar to the PC + graphics card way of doing it than the EE way of doing it. Or rather, the PC + graphics card way of doing it was copied from the workstation approach. Of course, the major problem spot of the PC + card approach to rendering--the horrible bandwidth from the motherboard to the graphics card (the AGP bus is a joke compared to what would be required to actually stream textures into the graphics card in real-time; as it is now, entire levels must be loaded into the graphics card memory and stay there until the next level is accessed)--is not such a problem on a high-end workstation. It'll be quite interesting to see how this GScube thing compares, but the specs are there for it to make a very inexpensive and powerful alternative to the standard SGI stuff.

  14. Why the EE is good for this stuff by ToLu+the+Happy+Furby · · Score: 2 · on Sony Announces GScube Development System

    One of these links has already been posted above, but if anyone wants a well-written, easy-to-understand-but-plenty-technical introduction to why the Emotion Engine is cheap to produce and a terrible general-purpose chip, but an amazing design for high-quality low-latency 3D graphics, assuming programers can figure out how to take advantage of it...

    start with these excellent articles from ArsTechnica:

    Emotion Engine overview

    Comparison of the EE's rendering process to that of a typical PC + graphics card

    The second article is, IMO, the particularly interesting and relevant one, since the approach to rendering taken by today's high end graphics workstations from SGI et. al. is more similar to the PC + graphics card way of doing it than the EE way of doing it. Or rather, the PC + graphics card way of doing it was copied from the workstation approach. Of course, the major problem spot of the PC + card approach to rendering--the horrible bandwidth from the motherboard to the graphics card (the AGP bus is a joke compared to what would be required to actually stream textures into the graphics card in real-time; as it is now, entire levels must be loaded into the graphics card memory and stay there until the next level is accessed)--is not such a problem on a high-end workstation. It'll be quite interesting to see how this GScube thing compares, but the specs are there for it to make a very inexpensive and powerful alternative to the standard SGI stuff.

  15. Arstechnica Slashbox? by Malc · · Score: 4 · on SETI@Home Version 3.0 Client Preview

    How about an Arstechica Slashbox? That way all of their stories could still be posted and we could get on with discussing something original. This story was posted on Arstechnica yesterday.

  16. ...But is it legal?? by jerkychew · · Score: 1 · on SETI@Home -- Running On A PCI Card

    I'm a member of Ars Technica Team Lambchop. zAmboni, One of our members, has brought up a very good point, which he posted on our . This site is advertising an add in PCI card for computers which contains anywhere from 1-6 CPUs, and is specifically designed to crunch SETI work units.

    There are two different cards, a single CPU card and a 1-6 CPU upgradeable card. The cards contain 2x64 kB level 1 cache and 32MB RAM per CPU. The CPU will run at 6.5 x the PCI clock. At the default PCI clock that woud mean a 214 MHz CPU (the CPUs have been tested up to 40MHz on the PCI Bus). As for crunching the work units, onboard ROM chips would contain the "unmodified" linux client, as well as the required routines of linux itself. The card ROM is flashable so when there is an upgrade in the SETI client it can be flashed into the card.

    The site claims it can process 1 work unit in 15 hours, and at the most, 6 work units in 16 hours (one for each CPU installed). The cost? $89 for the single CPU card, $129 for the upgradable card (with one CPU) and $69 for each additional CPU.

    I think that this is a pretty innovative solution. First off because it is using CPUs harvested from surplus military hardware. Specifically from target vector portion of the terrain following radar of cruise missiles. With the trend leaning toward using distributed projects as a solution for large scale computing, plus many of them planning to pay for crunching data, this may help people make some cash on the side.

    The problem I have with this personally is that this solution may not abide to the <a href="http://setiathome.ssl.berkeley.edu/license.h tml"><b>licensing
    agreement</b></a> for the SETI@Home project. Especially this portion: "Distribution of this software is prohibited". The company's FAQ sort of diverts this issue saying that this wasn't a patch and only uses an unmodified version of the client, but unless the company has an agreement with the SETI@Home team, they would be distributing the clients against the restrictions mentioned in the licensing agreement. As of this point I don't know if they do have permission to do this. I do not think that they do though. I cannot see the SETI@Home guys (who have a hard time raising fundage for their project) allowing a company to make a profit out of their work. Only time will tell to see how all of this plays out...legal proceedings may be a problem since the company is based in the Ukraine. I'll keep ya posted what I find out

  17. *clap clap clap* by ebbv · · Score: 1 · on Asus A7V Overclocking Confirmed


    good post :)

    i wish i had moderation ability in this thread :P

    ars has some good OCing articles, as does sharky extreme, curious parties should head over there.

    (sorry i'm too tired/busy to look up the full URLs :P)
    ...dave

  18. Re:The /. NTK community, what others? by BJH · · Score: 1 · on Galeon Web Browser: The Best Of Mozilla?

    Let's see: Memepool and RobotWisdom spring to mind... Also ArsTechnica, Kuro5hin and KernelTraffic (which isn't only about the kernel; the Samba summaries are also very good).

  19. the MiniBosses! by nutty · · Score: 3 · on Arcade Remixes And The Six Million Dollar Cabinet


    http://www.minibosses.com/

    These guys kick major booty. Check out such greats as Contra, Castlevania, Metroid, and more! All up in Mp3 for your listening pleasure.

    I saw this over at ArsTechnica a while ago. Once again, they kick ass. And they even play shows..!
    /nutt

  20. Re:Are you kidding me? by GeekLife.com · · Score: 1 · on Is Technology Killing Leisure Time?

    Glad to hear I'm not the only one wasting away my hours on the Web. Sure I work 50 hour weeks, but 10+ of that is spent on here, over on my site, or on any of the other half dozen sites I keep current with daily.

    I was beginning to think I was the laziest tech worker in the world.

    (Hmm, do any of my bosses read slashdot? I guess we'll find out)
    -----

  21. Ars Technica has a feature by Segfault+11 · · Score: 3 · on Using Lasers And Range Finders To Digitize Objects

    Ars Technica has a feature on this subject entitled: `Michelangelo Goes Digital'

  22. Ars Technica has a feature by Segfault+11 · · Score: 3 · on Using Lasers And Range Finders To Digitize Objects

    Ars Technica has a feature on this subject entitled: `Michelangelo Goes Digital'

  23. Re:This is old news by Penrif · · Score: 1 · on Using Lasers And Range Finders To Digitize Objects

    Yea, Ars ran it. It's old enough to be #2 in the top row.

  24. Wrong by Stickerboy · · Score: 2 · on MP3: On Artist Protection And Copy Protection

    The sound quality, to human ears, of a well-encoded 256-320kbit/s is exactly the same as a CD. Go to Ars Technica's archives for a statistical comparison of unencoded and encoded waveforms - at higher bitrates, the only part of the waveform that is affected by the encoding process is well beyond the range of human hearing.

    I'm not saying MP3s are good or bad from a philosophical standpoint, but I hate it when people use false arguments.

  25. More articles with explanations.... by Loganaxis · · Score: 3 · on Merging Unix And Mac OS

    Ars Technica has a good review of OS X Developer Preview 4, and another Q&A article that explains in detail questions about the BSD-ism/Mach-ness of the new OS.

  26. More articles with explanations.... by Loganaxis · · Score: 3 · on Merging Unix And Mac OS

    Ars Technica has a good review of OS X Developer Preview 4, and another Q&A article that explains in detail questions about the BSD-ism/Mach-ness of the new OS.

  27. Typo correction by John+Siracusa · · Score: 1 · on Merging Unix And Mac OS
    Whoops, "This link" should have pointed here.

    (Slashdot needs to allow post editing to correct typos.)

  28. Re:Doesn't say much by John+Siracusa · · Score: 1 · on Merging Unix And Mac OS
    is it really BSD underneath? They don't mention Mach at all. Was the NeXT stuff dumped completely?

    This link may provide some answers (check out question 3).

  29. Re:Doesn't say much by John+Siracusa · · Score: 1 · on Merging Unix And Mac OS
    is it really BSD underneath? They don't mention Mach at all. Was the NeXT stuff dumped completely?

    This link may provide some answers (check out question 3).

  30. Re:Doesn't say much by johnalex · · Score: 3 · on Merging Unix And Mac OS

    Ars Technica has covered Mac OS X extensively since some of the first developer releases. Many of your questions have been answered there. You can start here with a Q&A on OS X.
    JA

  31. XBox and PS2 - Side by side by Anonymous Coward · · Score: 1 · on Michael Abrash On X-Box Graphics
    After reading this article, check out this link (posted a while ago on slashdot) from ars technica, regarding the PS2 architecture:

    A Techincal Overview of the Emotion Engine

    I think most developers would agree, the PS2 employs a much more flexible architecture than the XBox. While the programmable shaders in DX8 are a great start, they are hardly as flexible as the generic-vector-unit approach that the PS2 employs. The XBox employs a multi-step semi-programmable T&L pipeline with three main components: The vertex shader, the texture unit, and the pixel shader. All three of these systems allow for greater flexibility than DX-compatible GPUs have offered in the past, but it's still not at the level of full pipeline programmability. With the DX8 shader API, you are given control over some aspects of the T&L pipeline, but this approach is ultimately not nearly as flexible or programmable as the PS2's multi-chip architecture. The PS2 doesn't even have a defined "pipeline" per-se; just a series of specialized chips (Emotion Engine CPU, two vector units, and the Graphics Synthesiser, as the main components) that can be utilized in whatever combination is most efficient for the given task. Initially there were reported architecture problems on the PS2 (such as bandwidth issues) but lately programmers are starting to employ new techniques (such as sending a new batch of microcode to the vector units every frame!) and getting around these assumed limitations (the recent "fix" to the aliasing issue is another example.) These techniques were missed initially because of the lack of familiarity with the PS2 and it's capabilities (such as the 2560-bit bus! ;-)

    The flexibility of the PS2 comes at the high price of incredible complexity. It remains to be seen whether programmers will thrive on this flexibility as a means to push the system to limits that the hardware designers themselves couldn't imagine (as they did with the playstation 1, n64, etc) or whether developers will prefer the much more straightforward design of the XBox. The current crop of excellent dreamcast games would seem to favor the latter point of that argument.

    Personally (as a game developer) I am a bit more attracted to the PS2. As I'm sure most programmers can empathize with, the lure of a complex and ultimately "hackable" design over a less flexible one, is immense. However, I can't deny the comparative ease of use of DX8 (as opposed to coding to the metal of the PS2), as well as my personal familiarity with using DX APIs. In the end, I find myself more excited by the incredible (as of yet untapped) potential of the PS2.

    paulb

  32. Re:Is it just me or... by Cloud+9 · · Score: 1 · on Crusoe To Be Used By Netwinder, IBM, NEC, Others

    If you like small and cheap, you might like the EspressoPC from Saint Song. Ars Technica did a review on it, and they seemed to really like it. Just think, a middle of the road machine twice the size of a Game Boy. Even better than a hacked I-Opener.

  33. More info at Ars Technica by Fandango · · Score: 1 · on The Challenges Of Integrating Unix And Mac OS

    Ars Technica has a new Q&A with some more info on how files are handled in DP4, as well as about other aspects of X that people have been asking about.

  34. Re:File MetaData by i,+Mac · · Score: 1 · on The Challenges Of Integrating Unix And Mac OS

    What you're describing exists on Mac OS 9 and Mac OS X now. The concept is called "application packages" on Mac OS 9 and bundles on Mac OS X.

    Basically, everything an application needs is encapsulated in a special type of folder. The folder is marked as a 'bundle' (Hence the precocious 'bundle bit' that's been in the Mac OS for years!) and to the Finder and any application that uses the system's file-handling routines, the folder looks like a single file.

    It can, of course, be opened by getting info on the bundle and clicking a button that says something to the effect of 'Open As Folder.'

    Within the folder are the application and all its support files, and as you are asking, you can open foo, you can open foo/bar, etc.

    So the idea of bundles is almost exactly what you're talking about - Apple isn't creating some sort of binary monstrosity but in essence made a folder pretend it's an application. When you double click, or 'open foo', the application opens. When you 'vi foo/etc/prefs.xml' you get the contents of prefs.xml.

    Simplicity and power rolled up in one. Let me know if I've got something mixed up about what you're asking for. In the meantime, some links:

    http://arstechni ca.com/reviews/2q00/macos-qna/macos-x-qa-2.html#q1 , and
    http://arstechni ca.com/reviews/2q00/macos-x-dp4/macos-x-dp4-2.html

    Oh, and poke around in the other Ars reviews of Mac OS X DPs... there's a lot of great information there, and it should explain a LOT about the structure and ideals behind the new OS.

  35. Re:File MetaData by i,+Mac · · Score: 1 · on The Challenges Of Integrating Unix And Mac OS

    What you're describing exists on Mac OS 9 and Mac OS X now. The concept is called "application packages" on Mac OS 9 and bundles on Mac OS X.

    Basically, everything an application needs is encapsulated in a special type of folder. The folder is marked as a 'bundle' (Hence the precocious 'bundle bit' that's been in the Mac OS for years!) and to the Finder and any application that uses the system's file-handling routines, the folder looks like a single file.

    It can, of course, be opened by getting info on the bundle and clicking a button that says something to the effect of 'Open As Folder.'

    Within the folder are the application and all its support files, and as you are asking, you can open foo, you can open foo/bar, etc.

    So the idea of bundles is almost exactly what you're talking about - Apple isn't creating some sort of binary monstrosity but in essence made a folder pretend it's an application. When you double click, or 'open foo', the application opens. When you 'vi foo/etc/prefs.xml' you get the contents of prefs.xml.

    Simplicity and power rolled up in one. Let me know if I've got something mixed up about what you're asking for. In the meantime, some links:

    http://arstechni ca.com/reviews/2q00/macos-qna/macos-x-qa-2.html#q1 , and
    http://arstechni ca.com/reviews/2q00/macos-x-dp4/macos-x-dp4-2.html

    Oh, and poke around in the other Ars reviews of Mac OS X DPs... there's a lot of great information there, and it should explain a LOT about the structure and ideals behind the new OS.

  36. Dual Durons "later this year" by Meerkat299 · · Score: 3 · on Overclocking The AMD Duron
    In the conclusion of Ars Technica's review of the Duron, Loki cites a couple of articles reporting that SMP support will come out for the Durons later this year:

    On the SMP tip, the Duron according to this news post at 2cpu.com will support SMP. This shouldn't come as a big surprise since it's built on the Athlon core. The SMP-ability would have to be specifically disabled, which is likely more trouble than it's worth. Later this year, AMD will be releasing the AMD 760MP chipset which will have ATA100, DDR SDRAM support, and SMP support. I'd love to see a board that I could start on dual Durons and kick up to dual Thunderbirds later on.

    HTH

  37. Dual Durons "later this year" by Meerkat299 · · Score: 3 · on Overclocking The AMD Duron
    In the conclusion of Ars Technica's review of the Duron, Loki cites a couple of articles reporting that SMP support will come out for the Durons later this year:

    On the SMP tip, the Duron according to this news post at 2cpu.com will support SMP. This shouldn't come as a big surprise since it's built on the Athlon core. The SMP-ability would have to be specifically disabled, which is likely more trouble than it's worth. Later this year, AMD will be releasing the AMD 760MP chipset which will have ATA100, DDR SDRAM support, and SMP support. I'd love to see a board that I could start on dual Durons and kick up to dual Thunderbirds later on.

    HTH

  38. Dual Durons "later this year" by Meerkat299 · · Score: 3 · on Overclocking The AMD Duron
    In the conclusion of Ars Technica's review of the Duron, Loki cites a couple of articles reporting that SMP support will come out for the Durons later this year:

    On the SMP tip, the Duron according to this news post at 2cpu.com will support SMP. This shouldn't come as a big surprise since it's built on the Athlon core. The SMP-ability would have to be specifically disabled, which is likely more trouble than it's worth. Later this year, AMD will be releasing the AMD 760MP chipset which will have ATA100, DDR SDRAM support, and SMP support. I'd love to see a board that I could start on dual Durons and kick up to dual Thunderbirds later on.

    HTH

  39. Can modern processors be trusted? by Silver+A · · Score: 2 · on Can Open Source Be Trusted?

    Since, according to an article in Ars Technica, modern processors will effectively rewrite code at execution time, can any program or OS running on a recent processor be considered a "trusted system" by the definitions used by Dr. Spafford and others?

  40. Links by Bjarke+Roune · · Score: 1 · on Genetic Algorithms Improve Combustion Engines

    Here is an introduction to Genetic Algorithms:

    http://cs.felk.cvut.cz/~xobitko/ga/

    Here is another example of a Generic Algortihm put to use, this time to apparently massively improve the wiring and therefore performance of Beowulf clusters:

    http://www.arstechnica.com/c pu/2q00/klat2/klat2-1.html

  41. Re:More good stuff about LinuxPPC by Phroggy · · Score: 1 · on Power Up That iMac
    I have nothing against LinuxPPC (except that I really hate RedHat); I was trying to point out that there are competing distributions (if you can call it competing).

    Yes, Mac OS X does use the Mach microkernel, although I think Mac OS X probably does it differently. Ars Technica has more on this.

    I never said I wasn't mad at Apple.

    The beta version of Mac OS X might be free, or close to free (as in beer), and in six months it'll be bundled with new Macs.

    --

  42. Re:Native OSes for Crusoe by Shoeboy · · Score: 3 · on Transmeta To Unveil New Notebooks Next Week

    With an open source OS and some hard thinking, it should be possible to come up with an instruction set for the Crusoe and a "port" of gcc which produces a very fast OS optimized specifically for your new instruction set.
    You seem to be out of touch with the trends in cpu design.
    Here's a nice simple intro -- it may have been a /. story, I can't remember.

    Basically, you don't want to code to the bare crusoe metal since that will keep transmeta from improving the architecture without breaking your software.

    The translation of x86 instructions can be done better than transmeta is currently doing it. By only exposing the x86 layer, transmeta gains the ability to totally redesign their chip without breaking any code. This is more important in the long run than a small speed increase.

    Also, the crusoe is optimized for translating x86. There's no guarantee that coding on the bare metal would be an improvement.

    --Shoeboy
    (former microserf)

  43. Re:Why should they keep the x86 compatibilty?! by Electric+Angst · · Score: 2 · on Transmeta To Unveil New Notebooks Next Week

    It would have been interesting to see a new, radically different design that does not keep the pathetic x86 compatibilty, but hey marketing is always more important ....

    Okay, I assume you haven't seen this article. So, let me give you the long and short...

    Unless you want to build an entire platform from the ground up, including OS, apps, and all, you have to stick with a legacy isa. (In this case, x86.)

    So, basically, it's not just a marketing stratagy, it's common sense.

  44. The Ad-Free Internet---avoid evil influences by Max+Hyre · · Score: 1 · on The Future of Making Online Revenue?

    I feel awfully lonely advocating this, but check out the Ad-Free Internet site. Curiously, the best discussion of it is on the Sluggy Freelance site.

    There are lots of folks who run small sites, costing them $45/month or so, but they can serve only a very limited clientele. Either they're honed to razor sharpness in who they appeal to, or they're not well known, or they're just not so hot. But, once a hot site gets noticed, and everybody and her brother start hitting it, the costs go up rapidly. Much as we like to pretend otherwise, the Internet is not free---we're mostly just freeloaders.

    Folks with popular sites, unless they're independently wealthy, must have some source of income from the site to support it, be it banner ads, a sugar-daddy corporation, sales of mugs and hats, or whatever.

    I don't know about you, but I need a lot fewer mugs than there are good websites out there.

    AFI's idea is to make it easy for sites and surfers to transfer cash in small amounts, paying for the one without costing the other very much, while protecting privacy and editorial independence. Think about it---if your site doesn't have to sell ads, it doesn't have to worry about advertisers (or owning corporations) being uncomfortable with the commentary.

    Wake up! If we don't grow up and get used to paying for what we get, someone else will, and we'll get what they want!

    I'm willing to pay for a good artist to write comics, or for Ars Technica to do unbiased reviews for me, or for a ton of other sites. It's only fair, and with the tens (hundreds?) of millions of surfers, none of us need pay much to get what we want. Unless we continue to insist it be fed to us at no (obvious, cash) cost. Then we will end up with the WWA (World-Wide AOL).

  45. Re:A little premature to call it obsolete by Jon+Erikson · · Score: 1 · on Is The x86 Obsolete?

    Errm, have you read this article at Ars Technica on the architecture of the K7? Does it look anything like the 8086? Of course not, there's a world of difference in the underlying architecture, it's just the ISA that has remained backwardsly compatible.

    And even in real terms, chips are getting faster over time. The growth may not be quite as explosive as the clock speed would indicate, but it's there. And Athlon's Sledgehammer will be a fully 64-bit processor as well...


    ---
    Jon E. Erikson
  46. Re:A smart move for Sega by albamuth · · Score: 1 · on Sega Looks At Licensing Dreamcast
    I think it's a bit late in the game. After all, Sony already said they were going to this, right? I believe there's a good Ars article on it.

    Besides, the Dreamcast has nothing on the Playstation hardware. 20 million polygons vs. 2 million, I believe the comparison is. Sure, the EE is hard to write for, mostly because it's such a radically different way to do 3D graphics -- but because it's such a killer design (at least the hype has said so) and the current status of the Playstation name being so high, I think people would rather develop stuff with the Emotion Engine.

  47. Re:Wrong, wrong, wrong... (your comment is) by Arker · · Score: 1 · on MacOS In A World w/ 2 Microsofts

    Let me guess, you haven't actually tried OS X, but you feel qualified to make an educated guess that it totally sucks based on reading a description and looking at some pictures.

    I didn't say it totally sucks. I said there are some UI decisions that are backwards. The traditional Mac window control layout, for instance, is unquestionably superior to the three-buttons-in-a-cluster approach found in Windows 95 - OS 10 copies Windows instead of the Mac layout, why? A screenshot is quite sufficient to spot this rather bizaare choice.

    Several reviewers have noted some extremely poor design decisions, see for example Ars Technica's observation on the OS 10 dock, or Ask Tog, who while trying to be positive, properly notes several steps backward in the UI.

  48. Re:How many people really want to run Aqua... by EEEthan · · Score: 1 · on MacOS In A World w/ 2 Microsofts

    Seriously. Am I the only one who finds it hard to believe that tons of people-including the people who are going to set up 'large internet servers' or whatever--are going to want to use Aqua? From what I've read about it-mostly at arstechnica, aqua was designed completely for novice users. It has a very pretty ui which at this point is dumber and slower than classic mac os. I just find it hard to believe that power users are going to give up the incredible power and ease of use of the cli. Yes, that's right, I said ease of use. I'm sorry, but all of this crap about 'linux isn't ready for desktop use' is a bunch of BULL SHIT. Maybe I'm not everybody, but back in the day, when I used win3.1/dos5, I used the dos cli for almost all my filesystem stuff. And since windows95 neutered the cli, I had been salivating for a new one. When I heard about linux, I had to give it a shot. And guess what my killer x11 app is? That's right, it's an Eterm. Personally, I think everyone's wrong. It isn't linux that's going to get easier-people are going to get smarter. The windows/Mac/Aqua and even KDE/GNOME paradigm is that we have to make linux easier to use, because people don't want to get smarter about their computers and extend themselves-but at the same time, the linux phenomenon itself is showing that people DO want to learn more challenging and powerful interfaces and applications. The CLI is just as viable an interface as a gui. Let's not forget what windows file management is-an ugly, ugly hack on top of dos directories. The reason I love blackbox is because it doesn't have a BS file manager, copped from windows. Why would I want that when I can use bash, which is undoubtedly faster and more flexible? I contend that it's no harder to learn how to do basic things in bash than it is to learn how to use the windows file manager-I know a lot of people who have never been told to right click in windows. The real future is the kind of support system which has been set up by linux users. This network of real people is far, far more important than the next product that MS or Mac thinks will 'revolutionize' the computing world. The revolution is here-we've been participating in it every time we've fixed a problem using well-written, contextual online help, or given the answer to a solution in a BBS. Where's the flourishing online community for Darwin? I'm not saying that it's not possible to create one, but I'm not sure that the major companies realize how big a lead linux has on them in terms of real community. If they think that a twenty-year old concept of 'ease of use' more or less created by the first Mac OS is going to save them, they're mistaken. I think it's funny-linux won't succeed because 'it doesn't offer anything that Unix hasn't?' Really? And of course, everyone knows this because free Unices have been around, available over the WWW with a well-developed help community for how long? While commercial, GUI-based, pay for each OS update, slowly learn to rip off the good stuff from Unix, platforms are apparently just breaking through? Sure. Mac OS X looks like a good product, but this article is a pretty big flight of fancy. If Mac OS X has anything to offer, we know how most people will get it-when a free OS replicates its good aspects. Sorry. If OS X comes out for Intel and is FREE maybe we'll talk.

  49. Re:Wrong, wrong, wrong... (your comment is) by Anonymous Coward · · Score: 1 · on MacOS In A World w/ 2 Microsofts
    I have to disagree with this quite vehemently
    Ditto:
    • not part of, but the complete kernel of MacOS X is open source. The validness of the lincense has been discussed in great length and I haven't heard about any serious issues with the APSL 1.1
    • since XFree has been ported to Darwin/MacOS X, you can actually choose whatever Window manager you want (some may need some porting too, but you do have the choice if you want)
    • you can customize the appearance of MacOS X as much as you want, even without using another Window manager, have a look here.
    • Since both the Dock and the Finder are simply applications, write a replacement you like better and presto, you've got it.
    You may have other (more valid) gripes with OS X, but the above is mainly FUD imho (and not deserving a +5 score at all).
  50. Re:Dynamic Optimization by vherva · · Score: 1 · on C Faces Java In Performance Tests

    For interesting results on the subject, see this Ars Technica article on HP's Dynamo optimizer.