Atheism states that there is no higher power in the world. That there is no god, gods or any higher form of life. And such gods cannot exist based on a few arguments.
Most atheists don't automatically impose a hierarchy on existence; that is to say, there is neither "higher" nor "lower". Those are constructs of religion, and only has the veneer of logic to one who can't see past their own religious leanings.
They'll become more and more valuable, universities with 16.7 million each will be forced to give them up, and we'll have more and more bureaucracy surrounding the IP address system. IPv6 will come in slowly.
The problem with breaking up a/8 is that you can't just spread around 16.7 million addresses to the individual machines around the globe that need them -- not unless we're ready to handle the massive explosion of routing table entries that would require (and we're not). CIDR still defines a routing hierarchy, where the huge swaths of free addresses exist within that hierarchy isn't necessarily geographically where they are needed, or where the systems that need them are going to be able to connect to them.
Not to say that some breaking up of largely unused/8's and/16's can't be done -- just that it's nowhere near as trivial a problem as most people seem to assume it is. It isn't like there is an abundance of resources in one area, so we can put them on a ship and send them to an area where the resource need exists.
Of course, all of this presumes that the holder of the/8 is using it in some sane manner where is it even possible to break the address space into routeable blocks...
Now, it has been at least a year since I messed with it (and gave up on it). If you think it has improved, I will give it another shot.
Well, I should admit that I'm still running a TiVo Series 2 in our home. The Series 3 isn't available here in Canada, the HD providers don't like to play well with others (because they don't have to here...grrr...), and we're still running a SD TV. So you could very well be right concerning HD output.
That said, IIRC pyTiVo does have settings for specifying the output resolution. I also found that a custom-build ffmpeg, built from the latest sources and enabling the various non-free A/V codecs my distro typically leaves out made a big difference (it turned out to be more efficient too, as I could compile it to use threads to saturate both cores on the server machine). My biggest concern wouldn't be so much that pyTiVo couldn't handle the HD video and AC3 audio, but that at 100Mbps you couldn't stream it fast enough to get really good HD quality. And AFAIK all TiVos max out at 100Mbps Ethernet (I'm running gigabit ethernet in my home, and the server has a very nice dedicated gigabit controller in it which, along with gigabit routers between the two makes the transfers somewhat more efficient, but you can't push the data faster than the TiVo will accept it).
It may be worth another shot, but because I'm one generation of TiVo behind you, I don't want to appear to be making blanket statements which I can't substantiate (which I unintentionally did. And am now correcting:) ).
I'm on the TiVo boat as well. If you want to serve up media from a PC, throw pyTiVo on it, and point it at whatever directory contains your video files. The format of the video files doesn't even matter -- on the back-end it uses ffmpeg to do the video conversion.
I have a refurbished Compaq with a 2.4Ghz Core2Duo I bought last year, and it can convert at about 200fps, easily saturating the TiVo's network capabilities. Once setup, the system just appears in the Now Playing List. It has easily passed the wife test in my home over and over again (especially as she has access to the movies directory over the network from the desktop of her Mac -- if she gets something she'd like to put up, she knows to just drag and drop it into the folder, and then start playing it from the NPL on the TiVo).
Can someone elaborate on why you'd want 48 full processors, rather than a processor with two (dual) or four (quad) "cores" (I'm presuming core in this case == FPU in the article).
Bad assumption. In this case, we're talking about (what you would consider) a 48 core CPU. Previous designs would have apparently contained only a small number of full processing cores, and a large number of parallel units suitable only for floating point calculations (which can be great for various types of scientific calculations and simulations). This new design contains 48 discrete IA x86 cores.
This idea is kind of broken for Linux. On MacOS, with 2 architectures, it makes some sense, since the actual executable code is not huge compared to data.
Mac OS X has more than two architectures to worry about. In my somewhat outdated version of XCode 3, I have six options that can be included when creating fat binaries: i386, x86_64, ppc, ppc64, ppc7400, and ppc970. And this doesn't include any of the ARM types used for the iPhone/iPod touch.
Even within a single processor family, sometimes it's desirable to target optimizations in certain specific processors.
Think about what you just did: you posted on Slashdot.
You used a web browser, which sent a few HTTP requests, represented as TCP/IP packets over an ethernet cable, which then traveled to an internet router, possibly via DSL or DOCSIS, got routed via OSPF and BGP, to a server running Apache and Perl.
And nowhere in any of that chain did I try to do so by spoofing your IP address.
Many people are vilifying Apple here, but the specific contents of this article have less to do with Apple, and more to do with Palm. Palm felt that Apple was violating the USB-IF Member Agreement by preventing one of their devices from being recognized as a legitimate sync target, and complained. The USB-IF found that Apple hadn't done anything to violate the agreement, but that Palm had.
I'm for interoperability as much as the next guy, but the mechanism which Palm chose to try to force interoperability was wrong, and was against their USF-IF Member Agreement. All of the open systems and standards you mention only function because devices, protocols, and hosts have specific standards for identifying themselves. If you break from these standards, you can expect things to not work. Palm was violating the USB spec, and whether you agree with their ends or not, the means to that end was wrong. If everyone were to flaunt the standard as they did, the standard would quickly become meaningless and would simply cave in on itself.
How do I do that? I don't even know where the song files reside, and even if I did take time to figure it out, I suspect most Itunes users have no clue.
Have you ever even looked? How about File -> Library -> Export Library? Or File -> Library -> Export Playlist? Or you can select the songs you want to copy from within the library/playlist window, and just drag and drop them to their destination. You don't even need to know where the song resides in any of these cases.
There are other ways to do this as well. On a song-by-song basis, right click on a song and select "Show in Finder" (or whatever the Windows equivalent menu option is), and the system will show you exactly where the song resides. Requesting the songs information also shows you its location on your system.
Pretty trivial to do actually, and would have been obvious to anyone willing to take 30 seconds to actually check.
Don't you then generally run into the filesize limits of fat32 with the disk images rather quickly?
Depends on your needs, and the original size of the key I suppose. I still own a relatively small, sub-gigabyte key for those relatively few times I need to use one (I'm running gigabit eithernet and 802.11n @ 5Ghz at home, so most transfers are via the network anyhow), so for me I don't tend to find it a big issue -- I'm not generally carrying around my own copies of virtual machines, so it hasn't been an issue for me. YMMV.
This is hardly a problem unique to Linux, although as you point out Linux does have its own special requirements that may make using FAT32 a bit problematic.
My home network is a combination of Mac OS X clients and Linux servers (Debian is so easily made so Mac friendly...). I have a USB key that I don't tend to use too often (online storage has removed much of that need), but I did decide at one point that easy interoperability between OS's was important, while at the same time needing OS-specific support from time-to-time, for specific applications and data.
My solution? I formatted my key for FAT32, and then created some disk images on the key formatted them to whatever OS-specific format was suitable (HFS+, ext3, etc.). By leaving sufficient room on the main FAT32 volume, I can readily store platform-neutral data, and inside the images I can store whatever OS-specific data (such as applications) that don't need to be accessible on every system I encounter.
This does require an extra mounting steps. In OS X, it entails plugging in the key, and then double-clicking on the DMG file to mount it. In Linux, I have to mount the ext3 image using the loop pseudo-device. Of course, this is only necessary if attempting to access data in one of the OS-specific formatted images: accessing shared data merely requires mounting the key itself (generally automatically handled by the OS).
It's hardly perfect, but it does mean you can have one key that can have both shared and OS-specific data on it for as many OS's as you'd like to have at your disposal.
Picked up a mini first of the year. This will be my very first upgrade.
As I understand it, the version numbers here are pretty much on par with a Microsoft OS version number so 10.5 to 10.6 will be like going from 98 to Win2k and should be handled the same way, upgrading will make for an unstable system so I should backup everything and do a fresh install. Is this conventional wisdom still correct?
You shouldn't have to backup your Mac just for Snow Leopard; ideally you've been keeping backups all along. Leopard made keeping good backups so brain-dead easy that all you have to do is get yourself an external USB/Firewire drive and plug it in, and let Time Machine take care of the rest. You don't even have to start the process in any way -- plug the drive in occasionally and let it do its thing in the background.
However, presuming for a moment you haven't being doing regular backups: yes. Backup everything first.
That having been said, with OS X I've never had to do a full wipe and reinstall. OS X has this very, very nice "Archive and Install" option that will move all of your existing system files into a "Previous System" folder, and then do a clean system install (optionally preserving all of your users and network settings, which I suggest). This does require a lot of free disk space, but it's safe and effective, and has always given me a very nice stable install of each new OS X release since Panther (10.3).
I'd like to use jumbo frames on my wired LAN. It's my understanding that all interfaces on a VLAN *must* use the same MTU, unless one wants to run into problems.
a) Is my understanding correct?
b) Can you configure each wired port into its own VLAN, so that one can connect 100mbit devices and jumbo-frame GigE devices into the same router?
(Sorry, too lazy to use Google atm.):(
Unfortunately, I haven't tried experimenting with this yet. My wired network is still primarily 100Mb/s clients -- I only have one dedicated gigabit client on the wired network (my MacBook is also a gigabit client, but I generally connect at about 300Mb/s via 802.11n, and only wire myself into the network when I need to do some sort of bulk transfer to my dedicated gigabit file server).
So unless someone else knows, you might have to resort to Google after all.
If you want to, you *can* work around them, by using a v6 tunnel provider (like Hurricane Electric). The configuration is not hard, but isn't something Grandma could do (not my Grandma, anyway)....
Those are the two big problems with v6 right now: ISPs that don't provide v6 addresses and home routers that aren't properly configured for v6 support. If ISPs start providing v6, though, router manufacturers will eventually pull their heads out and new routers will do the job correctly (and the manufacturers will probably also provide new firmware for those courageous enough to go that route).
Apple's Airport Extreme base stations have built-in IPv6 with auto configuration for clients. They even have built-in tunnelling. On their IPv6 configuration page, you just have to turn it on and specify whether you want it to be tunnelled or not, and you're all set. As an added bonus, all of their wired ports are gigabit, and the latest revision has independent 802.11b/g and 802.11n radios (so 802.11g clients don't slow down the network for 802.11n clients, and so that 802.11n clients can run in the 5Ghz range).
If you're into IPv6 at home, it's the best off the shelf solution available. I installed one last fall, and have been able to convert my entire network to using IPv6 internally, and many of the wired clients to gigabit speeds.
What makes you say that? A quick google search shows most sites estimate iTunes market share as between 50% and 70% of the legal downloads market.
But a monopoly in what? Not in the music that is being purchased -- the same songs are available from a wide variety of sources, including a significant number of other online stores, and from more traditional media retailers.
To turn this into a car analogy, if your town has 20 car dealerships, but one of them does between 50% and 70% of sales in your town, does that make them a monopoly? Absolutely not.
Apple doesn't have a position where it controls the actual end product; in this case the music itself. The fact that a large percentage of people seem to like their integration better doesn't rise to the level of forming a monopoly -- they just have a better product than their competition for the majority of consumers. That's not "monopoly", that's just good business.
You can still construct a program with a memory leak in Java.
Not in the way you propose.
Java currently uses a Concurrent Mark-and-Sweep garbage collector, whereby it can (conceptually) traverse the object tree from one or more root objects (in your example, Main), with any objects that are reachable being marked for preservation. In your example, both A and B would be left unmarked, as you can't get to them from Main any longer.
Once the marking phase is completed, the set of unmarked objects is garbage collected. In your example, both A and B would be collected.
Apple can't just publish an update that makes Pre stop working. If Pre is pretending to be an iPod, then all iPods would also stop working.
Unless, of course, Apple also pushes iPod firmware updates for every iPod model ever made through iTunes as well, such that synchronization requires some cryptographic authentication to proceed. Even the first generation iPods should be able to handle this.
I doubt that technical feasibility is any significant barrier for Apple to do this; what I really don't see is why they'd want to. It wouldn't be the first time iTunes has synchronized with non-Apple hardware, and it would only increase the market for their online services. Apple doesn't have anything to lose by having the Pre interface with iTunes, so why prevent it?
However, to actually do this I'd suggest a pretty beefy computer, like a Quad Core Mac Pro with at least 4GB of RAM, and that's going to set you back quite a bit. It would be very significantly cheaper to, as some others have pointed out, just buy two refurbished computers (I picked up a factory refurb Compaq late last year for $200 CAD that would be powerful enough for the submitters needs). Heck, you could buy 10 - 20 of them for what it would cost for the Mac Pro, and you could make a Beowulf cluster out of them for what the Mac Pro solution would cost (and I say that as a big fan of the Mac Pro itself -- it is simply major overkill for the submitters needs. Technical ability doesn't necessarily mean it's the best possible solution).
Addresses in very large organizations aren't necessarily used in ascending order. I'm sure IBM didn't just start assigning numbers contiguously from 9.0.0.1 (having worked there, I can virtually guarantee it). Indeed, big multi-national companies may be using their/16 networks to divide their network by geographic regions or business units, and then further sub-divide their/24's into local workgroups other other logical units.
As such, without some major renumbering work at such organizations, you can't just "reclaim" the wasted space in any reasonable manner. Routers still need to be able to get packets to the destination address (and know how to route them there), and without some form of compaction, you're not going to be able to easily reclaim addresses here and there without some serious routing table explosions. The unused addresses won't be contiguous, and getting a big organization to compact them into sufficient contiguous units that are going to be worthwhile to redistribute is going to be a very costly undertaking that they would (rightly) resist.
Re-distributing big/8's that are owned by large corporations just isn't going to happen. Getting perfect utilization for all the routable IPv4 address space was never going to happen, and never will. At least IPv6 seems to be designed with this fact in mind -- an organization can have an entire IPv4-sized address space all to themselves if they want to, and use it as densely or as sparsely as they desire, and we won't run out of assignable subnets.
I think the home router issue is the one that matters. I want IPv6, but simply cannot have it (unless I cough up lots of cash for a serious router).
Get yourself an Apple Airport Extreme. You don't need a Mac to run one, although the configuration software is Mac or Windows only (although it might run just fine under Wine). It has support for both true IPv6 packets to and from your ISP, and 6to4 tunnelling. Clients that connect to it need merely be IPv6 enabled -- on my home network (running gigabit/802.11n/IPv6) I've got OS X, Linux, and (virtualized) Windows clients all running IPv6, both within my private network, and to the public Internet at large.
A b.s. claim of a "Microsoft Tax" = Good
A b.s. claim of an "Apple Tax" = Bad
Slashdot's logic seems a bit inconsistant in it's application.
Not at all, the problem is with Microsoft attempting to re-define the nature of the "tax".
"Microsoft Tax" has always referred to the fact that one was traditionally forced to pay for an MS OS on machines that weren't manufactured by Microsoft, even if you didn't want it and had every intention of replacing it with something else (Linux in recent times, but in times past OS/2, DR-DOS, and other non-MS OS's). Indeed, at one point the "tax" was sufficiently insidious you were paying Microsoft a fee even when you bought a system from one of the big vendors that was pre-loaded with a non-MS OS (due to "per processor licensing agreements" MS had with the big vendors).
This new "Apple Tax" that Microsoft is trying to invent has solely to do with their world view that Apple systems have a higher TCO than Microsoft systems. There are a lot of really good arguments as to why their TCO calculations for comparable systems are purposefully bogus to try to inflate any existing differences beyond reasonable levels.
Regardless, if the application appears to be inconsistent, it's because Microsoft is trying to hijack an existing term that works against them by completely redefining it. Unfortunately, considering how frequently people are taking them to task for their numbers as opposed to their redefinition of the term, it seems they've been largely successful.
I personally defend the original definition. When you buy something with no Microsoft software on it, and it's more expensive than it should be purely because part of the purchase price is going toward a Microsoft software licence for software you're not even getting, that is a tax. Paying more for a high-end system versus a bargain basement system is not now, and never has been, a "tax".
OS/2 had a cooperative multitasking model. Applications assisted the OS in organizing information.
I'm sorry, but I have to call BS on you one this one.
OS/2 always used a preemptive scheduler, right from version 1.0 [0]. The only limitation to its preemptive model is that you couldn't preempt any thread running in kernel mode, which is pretty much par for the course with most multitasking OS's anyway.
Sorry, but the information in your post is total crap. FWIW I provide suitable citation below, so if you're interested in the topic you can verify this for yourself.
Yaz
(A former OS/2 developer, formally at IBM).
--------
[0] Deital, H.M and Kogan, M.S. The Design of OS/2, Addison Wesley, 1992, pp. 87.
Much of what you suggest is necessary already possible and is not a significant problem, however I feel you've missed the more significant issues that truly need to be dealt with.
Existing "routers" must keep working: if an IPv4 customer plugs his IPv4-only NAT "router" into his IPv6 network, that device must keep working, or customers will complain. Most likely, some sort of proxying or tunneling will be required, and customers will get RFC1918 addresses.
Or, more likely for quite some time ISPs will simply permit both IPv4 and IPv6 packets on their networks. There is no reason why this can't be done, and AFAIK every modern operating system already supports dual stack IP. The layer(s) below IP will still frame the packets in the same manner, and as the packets are versioned, devices that don't understand IPv6 will already drop the packets. This can be done for several years until the transition is complete.
IPv4 computers attached to IPv6 routers must keep working: that means that if a home NAT box connects to an ISP and gets an IPv6 address, it'll still have to hand out an RFC1918 IPv4 addresses to any connected host that asks for one. It'll have to do some tunneling or proxying so that the IPv4 machine "keeps working". People will return "routers" that break their Windows 98 machines.
Again, a dual stack solution solves this problem nicely.
IPv6 must be pitched as a beneficial feature: "routers" should have light-up "IPv6" logos so customers get a fuzzy, good feeling. Only later can certain sites risk being IPv6-only, and only much later can IPv6-only devices be marketable.
If we were to go with a dual stack solution, as IPv4 addresses run out and ISPs are forced to NAT them together, the benefits of IPv6 will eventually become obvious. One just has to wait for the "killer application", or for existing peer to peer applications (such as Skype) to break down (and that "killer application" for most people will probably be a new version of a media delivery system, or VoIP style application that won't work well under a multi-layer NAT).
Taking advantage of IPv6, when present, must be automatic: if operating systems require any configuration beyond what you need for IPv4, people will just choose IPv4. IPv6 must be detected and used automatically.
This is already true in the present day. Mac OS X, Linux, and Windows XP and Vista (and eventually 7) are all IPv6 enabled by default. IPv6 address autoconfiguration and routing is significantly easier to configure and run than in IPv4.
But here's what you've missed. There is invariably going to be some sort of transition period that is going to last many years, where both protocols are going to be in use. The client is only one side of the issue -- to be useful, the client still needs to be able to connect to useful sources of information on the network. And as things currently stand, IPv6-only hosts can't talk to IPv4-only hosts, and vice-versa. This will be a problem for IPv4-only hosts as more and more services online move to IPv6. Internet-wide dual stack support would be one solution, but that would entail a huge amount of overhead. For the web, proxies could come into play. I'm not sure if ISPs would be a fan of either solution. In a sense, the partitioning has already begun -- IPv4 hosts can't get to http://ipv6.google.com, for example, and the only reason why it isn't a problem is because Google is still available in IPv4 form (just without the added animation).
I'm already running a dual stack solution at home. I have a variety of IPv4 based devices (VoIP devices, a TiVo, my PlayStation 2) that continue to function, while my MacBook, PowerBook, and Debian server can do either IPv4 or IPv6 simultaneously. It's completely seamless and invisible, but primarily works because the I
All of Apple's current generation of AirPort based routers (including the Time Capsule units) are IPv6 ready for both wired and wireless clients, using either a 6to4 tunnel, or honest-to-goodness incoming IPv6 connections.
It's worth noting that Apple's routers are naturally OS independent, although the configuration client requires a Mac or Windows box (I don't know if the Windows version runs under Wine on Linux or not). So even if you're in an all-Windows environment, the Apple Airport Extreme is (IMO) still pretty much the best home router you can buy. I run one myself, and beyond having LAN and incoming and outgoing WAN IPv6 support (which my Macs, Linux server, and even my Windows Vista VM can all automatically make use of), I also have draft 802.11n support (including 5Ghz support), Gigabit Ethernet (which I do make use of), and the latest models even have dual radios for independent 802.11b/g in the 2.4Ghz range, and 802.11n in the 5Ghz range. They're about as advanced and as future-proof as you can get right now for a home routing device, and as such I highly recommend them to my Mac and Windows and *nix using friends (with the caveat that on *nix you will need a Mac or Windows system or VM to run the config software -- about the only downside to the AirPorts, although personally I like the software better than going through a web interface ala virtually all other home routers. I just wish they also had a Linux client, or perhaps even just a Java client for non-Mac/Windows OS based configuration).
the device is just not powerful enough to afford freeing up control on application that can run in background.
This is completely untrue, however the truth is more complex than most/. users seem to presume.
From everything that I've seen and experienced, the iPhone is more than powerful enough to support background tasks. Indeed, it already does with a number of built-in apps.
"Power" is not the problem from what I can see. As a phone, the iPhone needs hard guarantees as to processor availability. Let's face it -- if the iPhone permitted background tasks, and every stupid "toy" application from the AppStore decided to do background stuff, and it impinged upon the users ability to use the phone portion, the complaints would be absolutely deafening (both inside and outside/.). And rightfully so. Likewise, if the background multitasking for a dozen apps caused stutter or hiccoughs when playing back music or videos, the iPhone/iPod Touch would be garbage.
These issues are solvable, however I don't think XNU (the OS X kernel) has support for hard real-time computing (the Wikipedia article on XNU mentions it only has "very soft real-time support"). Apple would want some absolute computing guarantees for the telephony and multimedia playback capabilities of the iPhone/iPod Touch, and then ensure that only those functions have access to the hard-real time scheduler within the kernel. All other processes would get a standard priority-based scheduling from whatever CPU time was left after the real-time threads get their runtime.
So it's doable, but it does require some pretty significant core architectural changes to the software platform. Fortunately the hardware shouldn't have any problems with this, so it will be interesting to see what Apple comes up with. As an iPod Touch user, I'm a bit ambivalent about background execution support -- while there are some apps where it would be really useful (like for instant messaging, receiving VoIP calls, or listening to Internet radio), I also know that there are going to be a number of apps that will abuse this support unnecessarily. Time will tell, I suppose.
Personally, I think if Apple does introduce hard real-time support in XNU it would be pretty exciting.
Slashdot Mirror
Atheism states that there is no higher power in the world. That there is no god, gods or any higher form of life. And such gods cannot exist based on a few arguments.
Most atheists don't automatically impose a hierarchy on existence; that is to say, there is neither "higher" nor "lower". Those are constructs of religion, and only has the veneer of logic to one who can't see past their own religious leanings.
Yaz.
They'll become more and more valuable, universities with 16.7 million each will be forced to give them up, and we'll have more and more bureaucracy surrounding the IP address system. IPv6 will come in slowly.
The problem with breaking up a /8 is that you can't just spread around 16.7 million addresses to the individual machines around the globe that need them -- not unless we're ready to handle the massive explosion of routing table entries that would require (and we're not). CIDR still defines a routing hierarchy, where the huge swaths of free addresses exist within that hierarchy isn't necessarily geographically where they are needed, or where the systems that need them are going to be able to connect to them.
Not to say that some breaking up of largely unused /8's and /16's can't be done -- just that it's nowhere near as trivial a problem as most people seem to assume it is. It isn't like there is an abundance of resources in one area, so we can put them on a ship and send them to an area where the resource need exists.
Of course, all of this presumes that the holder of the /8 is using it in some sane manner where is it even possible to break the address space into routeable blocks...
Yaz.
Now, it has been at least a year since I messed with it (and gave up on it). If you think it has improved, I will give it another shot.
Well, I should admit that I'm still running a TiVo Series 2 in our home. The Series 3 isn't available here in Canada, the HD providers don't like to play well with others (because they don't have to here...grrr...), and we're still running a SD TV. So you could very well be right concerning HD output.
That said, IIRC pyTiVo does have settings for specifying the output resolution. I also found that a custom-build ffmpeg, built from the latest sources and enabling the various non-free A/V codecs my distro typically leaves out made a big difference (it turned out to be more efficient too, as I could compile it to use threads to saturate both cores on the server machine). My biggest concern wouldn't be so much that pyTiVo couldn't handle the HD video and AC3 audio, but that at 100Mbps you couldn't stream it fast enough to get really good HD quality. And AFAIK all TiVos max out at 100Mbps Ethernet (I'm running gigabit ethernet in my home, and the server has a very nice dedicated gigabit controller in it which, along with gigabit routers between the two makes the transfers somewhat more efficient, but you can't push the data faster than the TiVo will accept it).
It may be worth another shot, but because I'm one generation of TiVo behind you, I don't want to appear to be making blanket statements which I can't substantiate (which I unintentionally did. And am now correcting :) ).
Yaz.
I'm on the TiVo boat as well. If you want to serve up media from a PC, throw pyTiVo on it, and point it at whatever directory contains your video files. The format of the video files doesn't even matter -- on the back-end it uses ffmpeg to do the video conversion.
I have a refurbished Compaq with a 2.4Ghz Core2Duo I bought last year, and it can convert at about 200fps, easily saturating the TiVo's network capabilities. Once setup, the system just appears in the Now Playing List. It has easily passed the wife test in my home over and over again (especially as she has access to the movies directory over the network from the desktop of her Mac -- if she gets something she'd like to put up, she knows to just drag and drop it into the folder, and then start playing it from the NPL on the TiVo).
Yaz.
Can someone elaborate on why you'd want 48 full processors, rather than a processor with two (dual) or four (quad) "cores" (I'm presuming core in this case == FPU in the article).
Bad assumption. In this case, we're talking about (what you would consider) a 48 core CPU. Previous designs would have apparently contained only a small number of full processing cores, and a large number of parallel units suitable only for floating point calculations (which can be great for various types of scientific calculations and simulations). This new design contains 48 discrete IA x86 cores.
Seems like the type of processor Grand Central Dispatch was designed for.
Yaz.
This idea is kind of broken for Linux. On MacOS, with 2 architectures, it makes some sense, since the actual executable code is not huge compared to data.
Mac OS X has more than two architectures to worry about. In my somewhat outdated version of XCode 3, I have six options that can be included when creating fat binaries: i386, x86_64, ppc, ppc64, ppc7400, and ppc970. And this doesn't include any of the ARM types used for the iPhone/iPod touch.
Even within a single processor family, sometimes it's desirable to target optimizations in certain specific processors.
Yaz.
Think about what you just did: you posted on Slashdot.
You used a web browser, which sent a few HTTP requests, represented as TCP/IP packets over an ethernet cable, which then traveled to an internet router, possibly via DSL or DOCSIS, got routed via OSPF and BGP, to a server running Apache and Perl.
And nowhere in any of that chain did I try to do so by spoofing your IP address.
Many people are vilifying Apple here, but the specific contents of this article have less to do with Apple, and more to do with Palm. Palm felt that Apple was violating the USB-IF Member Agreement by preventing one of their devices from being recognized as a legitimate sync target, and complained. The USB-IF found that Apple hadn't done anything to violate the agreement, but that Palm had.
I'm for interoperability as much as the next guy, but the mechanism which Palm chose to try to force interoperability was wrong, and was against their USF-IF Member Agreement. All of the open systems and standards you mention only function because devices, protocols, and hosts have specific standards for identifying themselves. If you break from these standards, you can expect things to not work. Palm was violating the USB spec, and whether you agree with their ends or not, the means to that end was wrong. If everyone were to flaunt the standard as they did, the standard would quickly become meaningless and would simply cave in on itself.
Yaz.
How do I do that? I don't even know where the song files reside, and even if I did take time to figure it out, I suspect most Itunes users have no clue.
Have you ever even looked? How about File -> Library -> Export Library? Or File -> Library -> Export Playlist? Or you can select the songs you want to copy from within the library/playlist window, and just drag and drop them to their destination. You don't even need to know where the song resides in any of these cases.
There are other ways to do this as well. On a song-by-song basis, right click on a song and select "Show in Finder" (or whatever the Windows equivalent menu option is), and the system will show you exactly where the song resides. Requesting the songs information also shows you its location on your system.
Pretty trivial to do actually, and would have been obvious to anyone willing to take 30 seconds to actually check.
Yaz.
Don't you then generally run into the filesize limits of fat32 with the disk images rather quickly?
Depends on your needs, and the original size of the key I suppose. I still own a relatively small, sub-gigabyte key for those relatively few times I need to use one (I'm running gigabit eithernet and 802.11n @ 5Ghz at home, so most transfers are via the network anyhow), so for me I don't tend to find it a big issue -- I'm not generally carrying around my own copies of virtual machines, so it hasn't been an issue for me. YMMV.
Yaz.
This is hardly a problem unique to Linux, although as you point out Linux does have its own special requirements that may make using FAT32 a bit problematic.
My home network is a combination of Mac OS X clients and Linux servers (Debian is so easily made so Mac friendly...). I have a USB key that I don't tend to use too often (online storage has removed much of that need), but I did decide at one point that easy interoperability between OS's was important, while at the same time needing OS-specific support from time-to-time, for specific applications and data.
My solution? I formatted my key for FAT32, and then created some disk images on the key formatted them to whatever OS-specific format was suitable (HFS+, ext3, etc.). By leaving sufficient room on the main FAT32 volume, I can readily store platform-neutral data, and inside the images I can store whatever OS-specific data (such as applications) that don't need to be accessible on every system I encounter.
This does require an extra mounting steps. In OS X, it entails plugging in the key, and then double-clicking on the DMG file to mount it. In Linux, I have to mount the ext3 image using the loop pseudo-device. Of course, this is only necessary if attempting to access data in one of the OS-specific formatted images: accessing shared data merely requires mounting the key itself (generally automatically handled by the OS).
It's hardly perfect, but it does mean you can have one key that can have both shared and OS-specific data on it for as many OS's as you'd like to have at your disposal.
Yaz.
Picked up a mini first of the year. This will be my very first upgrade.
As I understand it, the version numbers here are pretty much on par with a Microsoft OS version number so 10.5 to 10.6 will be like going from 98 to Win2k and should be handled the same way, upgrading will make for an unstable system so I should backup everything and do a fresh install. Is this conventional wisdom still correct?
You shouldn't have to backup your Mac just for Snow Leopard; ideally you've been keeping backups all along. Leopard made keeping good backups so brain-dead easy that all you have to do is get yourself an external USB/Firewire drive and plug it in, and let Time Machine take care of the rest. You don't even have to start the process in any way -- plug the drive in occasionally and let it do its thing in the background.
However, presuming for a moment you haven't being doing regular backups: yes. Backup everything first.
That having been said, with OS X I've never had to do a full wipe and reinstall. OS X has this very, very nice "Archive and Install" option that will move all of your existing system files into a "Previous System" folder, and then do a clean system install (optionally preserving all of your users and network settings, which I suggest). This does require a lot of free disk space, but it's safe and effective, and has always given me a very nice stable install of each new OS X release since Panther (10.3).
Yaz.
I'd like to use jumbo frames on my wired LAN. It's my understanding that all interfaces on a VLAN *must* use the same MTU, unless one wants to run into problems. a) Is my understanding correct? b) Can you configure each wired port into its own VLAN, so that one can connect 100mbit devices and jumbo-frame GigE devices into the same router?
(Sorry, too lazy to use Google atm.) :(
Unfortunately, I haven't tried experimenting with this yet. My wired network is still primarily 100Mb/s clients -- I only have one dedicated gigabit client on the wired network (my MacBook is also a gigabit client, but I generally connect at about 300Mb/s via 802.11n, and only wire myself into the network when I need to do some sort of bulk transfer to my dedicated gigabit file server).
So unless someone else knows, you might have to resort to Google after all.
Yaz.
Apple's Airport Extreme base stations have built-in IPv6 with auto configuration for clients. They even have built-in tunnelling. On their IPv6 configuration page, you just have to turn it on and specify whether you want it to be tunnelled or not, and you're all set. As an added bonus, all of their wired ports are gigabit, and the latest revision has independent 802.11b/g and 802.11n radios (so 802.11g clients don't slow down the network for 802.11n clients, and so that 802.11n clients can run in the 5Ghz range).
If you're into IPv6 at home, it's the best off the shelf solution available. I installed one last fall, and have been able to convert my entire network to using IPv6 internally, and many of the wired clients to gigabit speeds.
Yaz.
...and learning how to best serve as America's hat.
I guess you weren't given the memo concerning our new motto:
Yaz.
What makes you say that? A quick google search shows most sites estimate iTunes market share as between 50% and 70% of the legal downloads market.
But a monopoly in what? Not in the music that is being purchased -- the same songs are available from a wide variety of sources, including a significant number of other online stores, and from more traditional media retailers.
To turn this into a car analogy, if your town has 20 car dealerships, but one of them does between 50% and 70% of sales in your town, does that make them a monopoly? Absolutely not.
Apple doesn't have a position where it controls the actual end product; in this case the music itself. The fact that a large percentage of people seem to like their integration better doesn't rise to the level of forming a monopoly -- they just have a better product than their competition for the majority of consumers. That's not "monopoly", that's just good business.
Yaz.
You can still construct a program with a memory leak in Java.
Not in the way you propose.
Java currently uses a Concurrent Mark-and-Sweep garbage collector, whereby it can (conceptually) traverse the object tree from one or more root objects (in your example, Main), with any objects that are reachable being marked for preservation. In your example, both A and B would be left unmarked, as you can't get to them from Main any longer.
Once the marking phase is completed, the set of unmarked objects is garbage collected. In your example, both A and B would be collected.
This is a serious over-simplification of how the entire system works; for further information I'd suggest reading Memory Management in the Java HotSpot Virtual Machine.
There are ways to leak memory in Java, but what you described isn't one of them.
Yaz.
Apple can't just publish an update that makes Pre stop working. If Pre is pretending to be an iPod, then all iPods would also stop working.
Unless, of course, Apple also pushes iPod firmware updates for every iPod model ever made through iTunes as well, such that synchronization requires some cryptographic authentication to proceed. Even the first generation iPods should be able to handle this.
I doubt that technical feasibility is any significant barrier for Apple to do this; what I really don't see is why they'd want to. It wouldn't be the first time iTunes has synchronized with non-Apple hardware, and it would only increase the market for their online services. Apple doesn't have anything to lose by having the Pre interface with iTunes, so why prevent it?
Yaz.
That's not true. In fact, DirectX 9.0 Shader Model 2 hardware support it's one of the advertised features of VMware Fusion. Indeed, Fusion can even provide exactly what the submitter is looking for (see the section "Two" Computers in One)
However, to actually do this I'd suggest a pretty beefy computer, like a Quad Core Mac Pro with at least 4GB of RAM, and that's going to set you back quite a bit. It would be very significantly cheaper to, as some others have pointed out, just buy two refurbished computers (I picked up a factory refurb Compaq late last year for $200 CAD that would be powerful enough for the submitters needs). Heck, you could buy 10 - 20 of them for what it would cost for the Mac Pro, and you could make a Beowulf cluster out of them for what the Mac Pro solution would cost (and I say that as a big fan of the Mac Pro itself -- it is simply major overkill for the submitters needs. Technical ability doesn't necessarily mean it's the best possible solution).
Yaz.
Addresses in very large organizations aren't necessarily used in ascending order. I'm sure IBM didn't just start assigning numbers contiguously from 9.0.0.1 (having worked there, I can virtually guarantee it). Indeed, big multi-national companies may be using their /16 networks to divide their network by geographic regions or business units, and then further sub-divide their /24's into local workgroups other other logical units.
As such, without some major renumbering work at such organizations, you can't just "reclaim" the wasted space in any reasonable manner. Routers still need to be able to get packets to the destination address (and know how to route them there), and without some form of compaction, you're not going to be able to easily reclaim addresses here and there without some serious routing table explosions. The unused addresses won't be contiguous, and getting a big organization to compact them into sufficient contiguous units that are going to be worthwhile to redistribute is going to be a very costly undertaking that they would (rightly) resist.
Re-distributing big /8's that are owned by large corporations just isn't going to happen. Getting perfect utilization for all the routable IPv4 address space was never going to happen, and never will. At least IPv6 seems to be designed with this fact in mind -- an organization can have an entire IPv4-sized address space all to themselves if they want to, and use it as densely or as sparsely as they desire, and we won't run out of assignable subnets.
Yaz.
Get yourself an Apple Airport Extreme. You don't need a Mac to run one, although the configuration software is Mac or Windows only (although it might run just fine under Wine). It has support for both true IPv6 packets to and from your ISP, and 6to4 tunnelling. Clients that connect to it need merely be IPv6 enabled -- on my home network (running gigabit/802.11n/IPv6) I've got OS X, Linux, and (virtualized) Windows clients all running IPv6, both within my private network, and to the public Internet at large.
Yaz.
Not at all, the problem is with Microsoft attempting to re-define the nature of the "tax".
"Microsoft Tax" has always referred to the fact that one was traditionally forced to pay for an MS OS on machines that weren't manufactured by Microsoft, even if you didn't want it and had every intention of replacing it with something else (Linux in recent times, but in times past OS/2, DR-DOS, and other non-MS OS's). Indeed, at one point the "tax" was sufficiently insidious you were paying Microsoft a fee even when you bought a system from one of the big vendors that was pre-loaded with a non-MS OS (due to "per processor licensing agreements" MS had with the big vendors).
This new "Apple Tax" that Microsoft is trying to invent has solely to do with their world view that Apple systems have a higher TCO than Microsoft systems. There are a lot of really good arguments as to why their TCO calculations for comparable systems are purposefully bogus to try to inflate any existing differences beyond reasonable levels.
Regardless, if the application appears to be inconsistent, it's because Microsoft is trying to hijack an existing term that works against them by completely redefining it. Unfortunately, considering how frequently people are taking them to task for their numbers as opposed to their redefinition of the term, it seems they've been largely successful.
I personally defend the original definition. When you buy something with no Microsoft software on it, and it's more expensive than it should be purely because part of the purchase price is going toward a Microsoft software licence for software you're not even getting, that is a tax. Paying more for a high-end system versus a bargain basement system is not now, and never has been, a "tax".
Yaz.
I'm sorry, but I have to call BS on you one this one.
OS/2 always used a preemptive scheduler, right from version 1.0 [0]. The only limitation to its preemptive model is that you couldn't preempt any thread running in kernel mode, which is pretty much par for the course with most multitasking OS's anyway.
Sorry, but the information in your post is total crap. FWIW I provide suitable citation below, so if you're interested in the topic you can verify this for yourself.
Yaz
(A former OS/2 developer, formally at IBM).
--------
[0] Deital, H.M and Kogan, M.S. The Design of OS/2, Addison Wesley, 1992, pp. 87.
Much of what you suggest is necessary already possible and is not a significant problem, however I feel you've missed the more significant issues that truly need to be dealt with.
Or, more likely for quite some time ISPs will simply permit both IPv4 and IPv6 packets on their networks. There is no reason why this can't be done, and AFAIK every modern operating system already supports dual stack IP. The layer(s) below IP will still frame the packets in the same manner, and as the packets are versioned, devices that don't understand IPv6 will already drop the packets. This can be done for several years until the transition is complete.
Again, a dual stack solution solves this problem nicely.
If we were to go with a dual stack solution, as IPv4 addresses run out and ISPs are forced to NAT them together, the benefits of IPv6 will eventually become obvious. One just has to wait for the "killer application", or for existing peer to peer applications (such as Skype) to break down (and that "killer application" for most people will probably be a new version of a media delivery system, or VoIP style application that won't work well under a multi-layer NAT).
This is already true in the present day. Mac OS X, Linux, and Windows XP and Vista (and eventually 7) are all IPv6 enabled by default. IPv6 address autoconfiguration and routing is significantly easier to configure and run than in IPv4.
But here's what you've missed. There is invariably going to be some sort of transition period that is going to last many years, where both protocols are going to be in use. The client is only one side of the issue -- to be useful, the client still needs to be able to connect to useful sources of information on the network. And as things currently stand, IPv6-only hosts can't talk to IPv4-only hosts, and vice-versa. This will be a problem for IPv4-only hosts as more and more services online move to IPv6. Internet-wide dual stack support would be one solution, but that would entail a huge amount of overhead. For the web, proxies could come into play. I'm not sure if ISPs would be a fan of either solution. In a sense, the partitioning has already begun -- IPv4 hosts can't get to http://ipv6.google.com, for example, and the only reason why it isn't a problem is because Google is still available in IPv4 form (just without the added animation).
I'm already running a dual stack solution at home. I have a variety of IPv4 based devices (VoIP devices, a TiVo, my PlayStation 2) that continue to function, while my MacBook, PowerBook, and Debian server can do either IPv4 or IPv6 simultaneously. It's completely seamless and invisible, but primarily works because the I
All of Apple's current generation of AirPort based routers (including the Time Capsule units) are IPv6 ready for both wired and wireless clients, using either a 6to4 tunnel, or honest-to-goodness incoming IPv6 connections.
It's worth noting that Apple's routers are naturally OS independent, although the configuration client requires a Mac or Windows box (I don't know if the Windows version runs under Wine on Linux or not). So even if you're in an all-Windows environment, the Apple Airport Extreme is (IMO) still pretty much the best home router you can buy. I run one myself, and beyond having LAN and incoming and outgoing WAN IPv6 support (which my Macs, Linux server, and even my Windows Vista VM can all automatically make use of), I also have draft 802.11n support (including 5Ghz support), Gigabit Ethernet (which I do make use of), and the latest models even have dual radios for independent 802.11b/g in the 2.4Ghz range, and 802.11n in the 5Ghz range. They're about as advanced and as future-proof as you can get right now for a home routing device, and as such I highly recommend them to my Mac and Windows and *nix using friends (with the caveat that on *nix you will need a Mac or Windows system or VM to run the config software -- about the only downside to the AirPorts, although personally I like the software better than going through a web interface ala virtually all other home routers. I just wish they also had a Linux client, or perhaps even just a Java client for non-Mac/Windows OS based configuration).
Yaz.
This is completely untrue, however the truth is more complex than most /. users seem to presume.
From everything that I've seen and experienced, the iPhone is more than powerful enough to support background tasks. Indeed, it already does with a number of built-in apps.
"Power" is not the problem from what I can see. As a phone, the iPhone needs hard guarantees as to processor availability. Let's face it -- if the iPhone permitted background tasks, and every stupid "toy" application from the AppStore decided to do background stuff, and it impinged upon the users ability to use the phone portion, the complaints would be absolutely deafening (both inside and outside /.). And rightfully so. Likewise, if the background multitasking for a dozen apps caused stutter or hiccoughs when playing back music or videos, the iPhone/iPod Touch would be garbage.
These issues are solvable, however I don't think XNU (the OS X kernel) has support for hard real-time computing (the Wikipedia article on XNU mentions it only has "very soft real-time support"). Apple would want some absolute computing guarantees for the telephony and multimedia playback capabilities of the iPhone/iPod Touch, and then ensure that only those functions have access to the hard-real time scheduler within the kernel. All other processes would get a standard priority-based scheduling from whatever CPU time was left after the real-time threads get their runtime.
So it's doable, but it does require some pretty significant core architectural changes to the software platform. Fortunately the hardware shouldn't have any problems with this, so it will be interesting to see what Apple comes up with. As an iPod Touch user, I'm a bit ambivalent about background execution support -- while there are some apps where it would be really useful (like for instant messaging, receiving VoIP calls, or listening to Internet radio), I also know that there are going to be a number of apps that will abuse this support unnecessarily. Time will tell, I suppose.
Personally, I think if Apple does introduce hard real-time support in XNU it would be pretty exciting.
Yaz.