Of course non-admin users get authentication dialogs. Why do you think there's an entry for the name? It is NOT simply "sudo". The only difference for authentication for admin and non-admin is that the non-admin has to enter an administrator name, the admin has the name already filled in.
It is NOT paranoid to be worried about "existing applications [being] surreptitiously replaced". That's the WHOLE POINT of securing your system. System Preferences is not writable by admin, that's good. But I can delete System Preferences and replace it with my own version. Now you're screwed, the next time you go in to System Preferences and authenticate, my code can now do anything. I don't know what gets loaded and run just by being there in/Library/Preference Panes, but that's also read-write to admin. If some of that gets run just by opening System Preferences, without even clicking on the icon, then again you're screwed.
If there are libraries that can be loaded from insecure places by a supposedly secure application (i.e. one that does run with elevated privileges), that application is insecure by definition unless it takes extreme measures to isolate the library (run in a separate process with no extra privileges). Same thing can be said of configuration files that are assumed to be secure, but aren't really. If there's no special checking by the privileged program, it's easy to get it to do insecure things by messing with its config file. And half of all files in Mac OSX seem to be config files, many of them writable by admin.
Oh, HERE'S a good one, ANYONE can write to/Library/Caches - which means that if an application that uses it doesn't validate what's in the cache, you could probably compromise it.
How about putting stuff in/Library/StartupItems (not writable by admin, but it can be deleted and recreated, and the system will run stuff in it as root at next restart). 10.4, they've tightened security on this (if the item isn't owned by root or isn't read-only to other than owner, system startup will ask the user if they want to run it), and they've also put in a different mechanism which may also improve security there.
The fact is, admin can do things that can compromise the system with no further authentication, and there is NO good reason to actually be running as that user except when doing administrative stuff (installing/removing programs, updating the system), and with fast user switching, there's no drawback at all to not running as an administrator.
I haven't had any problems with it checking, but trying to download updates, without installing, as a non-admin IS a problem (and if you have it set to "automatically download in the background", that's what it is probably doing). It doesn't ask for privileges, but after it finishes downloading it tries to expand it into a directory that requires group admin. Telling it to install asks for privileges first, and then the expansion works. One of the very few places where things don't work correctly as non-admin (again, this is in 10.3, I don't know if they've fixed it in 10.4).
It also doesn't remember if you've downloaded but not installed, once you leave the Software Update program, which is really stupid. In fact, it should check to see if the updates being requested are in the Packages directory already, whether or not it thinks it has downloaded it (and verify it against the checksum from the server). That way, if you are doing a re-install, it doesn't need to re-download things you already have. It would also be nice if it kept enough information to be able to re-update your system from downloaded packages automatically without needing to go to the server at all - i.e. keep track of which packages that you've kept are current, and in which order things need to be installed, to bring everything back to current.
All of the applications in/Applications are writable by group admin. That's a huge security problem.
/Library and a lot of stuff underneath it is writable by group admin. That's Internet plug-ins, printers, trusted certificates, help files, scripts, some frameworks, stuff in Application Support - a lot of stuff points things at executables, or has scripting capabilities, or is otherwise assumed to be trusted.
Much of the stuff in/Developer is writable by admin. That means something could do a sneak attack, so anything you build and distribute is a virus vector.
There is absolutely no reason to run as an administrator, except to do installations (you can do installations as a non-administrator, but ownership of installed files seems to be cleaner if you always do it from one login, and then the same principle applies - if you do it using your normal login, then some things will be owned by you which means they are vulnerable).
With user switching enabled, there's even less reason to run as an administrator, since you can easily switch back and forth. Even for sudo, all you need to do in a terminal window is su to your admin login first, then you can sudo to your heart's content.
Isn't that what I said? NTP does it incorrectly, but the underlying protocol can be easily adapted to a none-broken implementation. There's nothing about NTP that says anything other than ntpd has to care about what the current NTP timestamp is, not even the kernel, and certainly not user programs.
In 10.3, the group for/Applications is admin, so only user accounts that are set to be Administrators can install or remove applications. Maybe they changed this in Tiger. All of the applications I looked at are also modifiable by group admin. That's why I tell people that they should set up an administrator account, and disable it for themselves. The obvious user name, admin, is blocked by Apple's account administration routines, though (you can create it as your initial user in 10.3, but they stopped that in 10.4). Yes, normally you get a group created that is the same as your user name, but it went ahead and used "staff" instead. I suppose it is a good idea not to have something obvious as your admin account, though.
There are very few things that you need to actually be logged in as an administrator, and even fewer where you'd need to log in as root (usually easier to just open a terminal window and use su (if you've enabled the root password) or sudo).
I don't know about Microsoft Office, but the Office "Test Drive" behaves abominably with respect to admin rights. You basically have to install it and run it as an administrator, but the failure modes if you don't are not obviously because you're not running as the right user. Stupid stupid stupid.
Unless you have your keychain password set to something besides your login password, so it doesn't automatically unlock it when you log in, it shouldn't even ask you for your password then. My parents usually forget their password, since it is set to auto-login for them, except when I'm visiting and using the machine (and thus either logging them out, or using user switching, either of which requires they enter their password to get back on).
I wouldn't call 36K bytes over 1800 years a serious problem. By then, we'll need local-planetary-time adjusted from Galactic Time for different planets and speed-of-light and relativistic corrections anyway, they'd be thankful for a 36K solution.
Leap 1972 Jun 30 23:59:60 + S Leap 1972 Dec 31 23:59:60 + S Leap 1973 Dec 31 23:59:60 + S Leap 1974 Dec 31 23:59:60 + S Leap 1975 Dec 31 23:59:60 + S
... (damned lameness filter - 15 more lines from 1976 to 1995 removed)...
Leap 1997 Jun 30 23:59:60 + S Leap 1998 Dec 31 23:59:60 + S
and it is so difficult to add:
Leap 2005 Dec 31 23:59:60 + S
I see why you think it is a serious problem.
Why does it matter how many seconds it is until July 5, 2009 at 5:31:05 UTC? If the number of seconds matters, state it as number of seconds. If the correct local time matters, state it as a local time (heck, you don't even know for sure if DST will be in effect or not). If you're trying to pre-program a telescope, you'll have no idea of the exact correction until that day, anyway.
I do see one potential problem, and that is storing future dates (i.e. reminders/alarms) as a Unix seconds-from-epoch value. In that case, you are indeed better off storing things as uncorrected values, i.e. each day is exactly 86,400 seconds long. BSD (or at least, the man pages on OSX indicate) a function time2posix() and posix2time(), which accounts for this difference (POSIX basically requires time values to not have leap-seconds added in, which means the system clock has to stop for 1 second at a leap second, and the actual number of seconds (as a time interval) since Jan 1 1970 is off from the time value returned by time() by the number of leap seconds since then).
They basically are proposing to use TAI as the legally defined time for things like transactions, date changes, etc. TAI would become the "official time" instead of UTC (of course, contracts and such would still generally refer to local time, which would be TAI corrected for timezone).
I have two clocks that use 60Hz to tell time. They stay exactly in synch, but vary from NTP/WWV time by a varying amount each day (the frequency drifts slightly, but is corrected so the right number of cycles (5,184,000 = 60 * 86,400) occurs for each day. I believe they do NOT ever try to insert leap seconds, that's a function of whatever is converting interval timing into time-of-day.
You can't maintain a highly accurate clock without external synchronization. Why doesn't your external synchronization source include leap-second information (including when the next one is going to occur, as soon as it is known)? It's no more error prone than having the clock data itself be wrong.
The application itself should be tested against leap-seconds, there's no reason you should have to test to see if a particular leap-second is going to cause a problem (just as you don't have to test it for each time the clock rolls over from 23:59:59 to 00:00:00). You add ONE LINE to a leap-second file, if you did it right, or just let NTP do it for you if you did it even more correctly.
Note that the NTP epoch implementation is itself arguably done incorrectly. A reasonable kernel can handle it better by having the NTP daemon update a leap-second file, keep a fixed Unix epoch and correct to UTC in the libraries while keeping a constantly running clock going.
Because it is really easy to simply have a flag saying "at the end of this day, the last minute will have 61 seconds in it, going from 0 to 60 instead of 0 to 59." Most clocks don't need to be so precise that they have to even deal with that, they'll just re-synch with the new corrected time. DST is much more disruptive, and there's a fine mechanism to handle it in the computer world (or, at least, ones with decent operating systems).
NTP has provisions for it, standard Unix time libraries have provisions for it, or you can ignore it since your clock is probably off by 2 or 3 minutes anyway. If you need to be precise to the sub-second, you already have the mechanism in place to automatically deal with it.
The accumulated leap-second field is also being used in GPS units to distinguish between different 1024-week periods (there are around 12-13 leap seconds in a 1024 week period, so it can be pretty fuzzy and still usable for a couple hundred years after their manufacture date, even if it changes to 10-11 or 14-15 leap seconds in that 1024-week period).
There is no mechanism in place to handle a 10-second or 1-hour leap - and they won't be tested for real for a long period of time. If you think Y2K was bad (in terms of expenses to go through all code, in terms of the panic and consternation it caused), wait until Leap Hour hits. The leap-second mechanism gets tested currently every 18 months or so, and again most equipment is so imprecise it just doesn't care if it is 39 seconds fast or 40 seconds fast; and anything that does care already has the ability to do it easily and correctly.
When the "World Wide Web" came out of CERN in 1990, it was little more than an obscure research channel until the development of Mosaic. This was done at the University of Illinois. If you don't know where the University of Illinois is, I'll give you a hint. Start looking in the United States.
Honestly, some people have no sense of history. Everything is built on everything else. HTML and HTTP are built on other similar protocols and formats. There was Gopher, there was SGML, there was Ted Nelson's Xanadu and hypertext and hyperlinks. There were already search engines (Archie and Veronica). What we ended up with is certainly not the best we could have had.
l12n? If you must use stupid "omitted letter" abbreviations (i18n was cute, but stupid), at least count the letters correctly! There's i18n (internationalization), l12y (localizability), g11n (globalization), and l10n (localization). Not l12n. Maybe l14n, that would be localizabilition, if you're George Bush.
First, you'd do better panhandling. You're making $60 (€50)/week, I'm sure you could get more then $10/day in change (or even picking up aluminum cans, if they do recycling there).
Second, I don't know what you think he meant by "top of the line Mac G5", but either you go all the way (16GB ECC RAM, 1 TB disk, dual 30" cinema displays (and the QUADRO FX 4500 card to drive them) , Bluetooth/Airport, modem, Wireless keyboard, Fibre Channel Card, OSX Server, Applecare), coming out to about €23,000 each, or go with what he probably meant, which is a reasonably decked out machine, which would currently be the Quad (dual dual-core) 2.5GHz machine, base price of $3,299, boost to 4GB ECC, 500GB disk and add Airport/Bluetooth for about another $1,800, or about €13,000 for 3 of them. Now, that's probably a bit of an exaggeration, or he took an awfully long time putting a system together, or he gets paid so much that his finances aren't really applicable to "most people", not just student types working for a pittance. But that's one hell of a lot of system for about €4,300 ($5,100). If he wasn't quite so pushy about "top of the line", three dual-core 2.3GHz with 1GB/250GB comes out to about €6,800 ($8,100). At $200/hr, he'd only need to spend 40 hours researching, ordering, putting together, testing, sending back and re-ordering (including calling customer support), re-installing operating systems a few times, etc. Note: all prices are from US Apple Store, I realize that prices in Europe are a bit higher, especially with the VAT added on.
Or did you mean to say 13,000 Euros instead of 33,000?
As you say, you're a poor student, and you can't afford a good computer. It doesn't surprise me that you can't afford a Mac yet.
So you moved the condition that you're actually checking to the end of the loop (and you forgot to initialize "data_left_to_process", but let's assume it is set to "true" to begin with - but what if it isn't true?). So wouldn't it make more sense to use an explicit do {} while (check_for_more_data())? Except that would reveal the major bug you've introduced which is that it will fail if there's no data at the beginning.
In addition, you haven't indicated what happens if "valid_preamble()" returns false - how does "valid_data()" handle an uninitialized "data" variable? Or are you omitting a bunch of nested if conditions? How is that more clear?
If you're holding that up as an example of not "poorly written code", you've failed. I can embed exit conditions in variables that get set in hundreds of lines of code just as easily as I can embed breaks and continues, you'll still have to search for it. The problem is a loop that covers hundreds of lines of code, not where in the loop the exit condition is determined. You're going to have to read the code anyway if you want to know what it does, knowing the loop exit conditions at the beginning of the loop is the least of your worries (unless the loop exit condition can actually BE determined at the beginning of the loop, in which case it probably IS a simple loop). What you're doing is making it more complicated in the name of simplifying it. If it is a complicated loop, it will have complicated exit conditions.
Using break and continue and return appropriately is in no way "poor coding technique", and if you think that you shouldn't use break because "it can be proven that it isn't absolutely necessary", I suggest you start doing all your coding in Brainfuck or some other Turing tarpit.
I consider for (;;) to be slightly more aesthetic than while (1) (as even the trivial logical expression "1" doesn't have to be optimized away).
Which is why the "last mile" owners should only be providing connectivity to connect to the consumer's ISP of choice, on an equal footing with any other ISP, including any owned by or operating for the benefit of those owners. Charge a fair price for the connection, and compete on the basis of service and offerings as an ISP. The ISP shouldn't be able to get away with poor service on the basis of getting favored status from a natural monopoly. Even where there are two competing providers (e.g. cable and telephone), that isn't enough of a free market to keep prices fair. Perhaps with the addition of power-line and Wi-Max (satellite isn't a competitor, people only use it when it is the ONLY option offered), there will be enough competition to start making it a free market, but even with those, it is still a limited natural monopoly - there's only so many towers and cables and lines that can be strung around a town, so early providers get a lock and then can keep prices artificially high, even without collaboration. You can't have a free market when the "barrier to entry" is so high, so regulation is necessary. I wish the FCC would start providing that regulation.
There's nothing magic about using LEDs as the light source to excite the quantum dots. Use a standard fluorescent bulb, except use quantum dots instead of whatever phosphor is normally used (different ones produce different spectrums, which is how you get "warm white" vs "cool white" vs "natural" vs "grow lights", etc). These would just be a wider-band spectrum "natural" than current phosphors can do.
The eye can adjust to color temperatures quite well. What the CRI measures is the completeness of the spectrum, not the temperature. The color temperature is based on only the summed effect of the different frequencies. You can have vastly different spectrums that result in the same color temperature, for example in a television where only three different fairly narrow bands are used to produce a wide range of colors.
Two problems with using such narrow bands is that different people have different frequency sensitivities, so an image that looks correct for one person won't look "natural" for another (I've often wondered how effective going to a 5 or more band system would be for television); and that something that has its own narrow bands of reflected color that don't match the bands of incident light will look different than it would in "true" white light (of whatever color temperature).
With quantum dots effectively spreading the bandwidth of the light source into a wide spectrum light (which is not a new idea; I'm not sure why this is being considered a revolutionary new discovery, unless they were using novel techniques to produce the right mix of the right sizes), you could use any other low-power light source, not just LEDs. LEDs are convenient for some things because they can be used at very low power and last a long time. Where you need more light, you could use quantum dots with low-pressure sodium, for example, or conventional fluorescent bulbs except using quantum dots with a wide spectrum to do the fluorescing. The article also mentioned but didn't expand on using direct excitation with electricity to get quantum dots to give off light, which could be even more efficient.
Apple Computer's market share of the U.S. computer market climbed to 4.3% in the September quarter, according to market research firm IDC. That's an increase from 3.3% from the year-ago quarter. Apple was the number five vendor in the U.S. market, behind Dell, HP, Gateway, and Lenova (formerly IBM's PC division), and the company showed a steeper climb in U.S. unit sales, 44.6%, than any other company in IDC's report. (Dated: October 17, 2005)
People sure have short memories. Not long ago, all the articles were about "beleaguered Apple". I guess that was because, back then, all the journalists were using Windows machines, right? The difference now is that Apple somehow convinced them all to switch using underhanded techniques like making good computers.
And, while business use is increasing, I'm not sure what percentage of the market shares are for personal vs. business use:
The report found that 17 percent of businesses with 250 employees or more were running Mac OS X on their desktop computers. Twenty-one percent of businesses that had 10,000 or more employees used Mac OS X on their desktop.
Mac OS X Server is also doing well with businesses. Nine percent of companies with 250 employees or more used Mac OS X Server, while 14 percent of companies with 10,000 employees or more used Apple's Server software.
but I believe that personal use is significantly higher than business use for Macs, and significantly higher for business use than personal for Dell, meaning that the percentage of PEOPLE who are more interested in what Apple is doing compared to what Dell is doing is a lot higher than what you think.
I personally am excited to see new products out of Apple. The new Power Macs and Powerbooks are more exciting to me than the announcements about new iPods (video or otherwise) or the new iMacs, even though those show more the direction Apple might be headed. It shows that Apple has not yet abandoned the PPC market, that current products really will be supported for some time to come despite a transition to Intel processors.
BTW, for anyone who is positive that Apple will stop using PPC processors by the end of 2007 should remember that Steve Jobs denied the possibility of a video iPod right up until he announced it. If IBM is producing chips in 2007 that meet needs of Apple customers, there's no reason for Apple to stop using them simply because in 2005 they said they would. They still have to deal with getting developers to produce 64-bit native Intel code , which is much less of a problem on the PPC architecture (since PPC-32 is a subset of PPC-64). With the x86-64, you get more improvement in performance than simply increasing register size and address space (which, depending on the application, might not get you much if anything). With PPC, if there's no need to go to 64 bit, then there's no performance penalty for not making the move. For low power stuff (e.g. laptops, Mac Mini), the Intel line will probably do fine. For high performance, they may find that upcoming IBM chips continue to make sense.
"They plug in and go" and "behave how you expect" - what part of that is "not as useful or versatile out-of-the-box"? Are you comparing it to the packages available with a typical Linux installation? You realize that, for about the same amount of effort of doing that initial Linux installation, you can install pretty much all of those on a Mac (of what isn't already installed by default). Otherwise, what can't it do out-of-the-box that you think it should be able to do?
The alternative to PDF for most people is to send Microsoft Word documents. PDF is much better.
I really prefer PDFs, at least for "reading a manual" (or "reading a novel"). I think the problem is Adobe Reader, not the PDF format. I usually use Preview for reading PDFs. I have a screen that rotates (though I don't have a driver for Mac OSX that flips the display); with Preview, I just rotate the view, then go to full screen, and it's much easier to read than most HTML on-line documents. I don't even need to do the screen flip when reading it on a 20" iMac G5. If I want to search, I just search right there, I don't have to somehow do a search over the set of different pages that the HTML doc is organized in (if I'm even given the option).
I often want to have the whole thing in a fixed form, not subject to random server crashes, Internet problems, or someone deciding to remove the content. I can download a PDF as one file, I don't have to either try to grab all the pages, or hope that the web site has a tarred or zipped version I can download (and then find the "index.html" page in the middle of all of it to start up in). I'll often save a web page where I want the content (as opposed to links) as a PDF (e.g. Print to a PDF). Only thing I'm missing is ability to print additional files to the end of what I just saved.
The only time scrolling is a chore for me is when I don't have a decent screen, and the document is done in two (or more) columns. Of course, a web page organized the same way would be just as bad.
I really prefer PDFs. I think the problem is Adobe Reader, not the PDF format. I usually use Preview for reading PDFs. I have a screen that rotates (though I don't have a driver for Mac OSX that flips the display); with Preview, I just rotate the view, then go to full screen, and it's much easier to read than most HTML on-line documents. If I want to search, I just search right there, I don't have to somehow do a search over the set of different pages that the HTML doc is organized in (if I'm even given the option). I can download the whole thing as one file, I don't have to either try to grab all the pages, or hope that the web site has a tarred or zipped version I can download (and then find the "index.html" page in the middle of all of it to start up in). I don't even need to do the screen flip when reading it on a 20" iMac G5.
The only time scrolling is a chore for me is when I don't have a decent screen, and the document is done in two (or more) columns. Of course, a web page organized the same way would be just as bad.
iMac G5 (1.8GHz, 512MB): 15 seconds to shutdown, 50 seconds to boot (inluding auto-login, dock, menu bar and desktop files displayed, at which point system is usuable), 55 seconds to restart (shutdown and boot, minus hardware POST), 7 seconds to sleep (until the disk spins down), slightly less than 5 seconds to unsleep (including wireless/DHCP negotiation).
The obvious way to do fast booting is to complete initializations and snapshot memory. On reboot, device drivers have to verify their devices are still connected and re-initialize them, system time needs to be updated, network connection needs to be re-established, and system should be ready to go. Load time from disk is minimal, but you still have to wait for spin-up and init, so storing the post-config memory image in flash makes more sense - by the time the disk has spun up, the OS is ready to go. The big speed-up comes from not scanning for devices, just assuming that the config hasn't changed, verify devices are there, and initialize them to known state. OS has to handle new devices, new busses, new cards while it is up (i.e. everything is a loadable module). Sleeping/hibernation then is just a variant on the theme (boot basic OS from flash, initialize devices, re-load active processes which are written out to disk). The fun part is figuring out if anything has changed while the OS has been suspended.
Slashdot Mirror
Of course non-admin users get authentication dialogs. Why do you think there's an entry for the name? It is NOT simply "sudo". The only difference for authentication for admin and non-admin is that the non-admin has to enter an administrator name, the admin has the name already filled in.
It is NOT paranoid to be worried about "existing applications [being] surreptitiously replaced". That's the WHOLE POINT of securing your system. System Preferences is not writable by admin, that's good. But I can delete System Preferences and replace it with my own version. Now you're screwed, the next time you go in to System Preferences and authenticate, my code can now do anything. I don't know what gets loaded and run just by being there in /Library/Preference Panes, but that's also read-write to admin. If some of that gets run just by opening System Preferences, without even clicking on the icon, then again you're screwed.
If there are libraries that can be loaded from insecure places by a supposedly secure application (i.e. one that does run with elevated privileges), that application is insecure by definition unless it takes extreme measures to isolate the library (run in a separate process with no extra privileges). Same thing can be said of configuration files that are assumed to be secure, but aren't really. If there's no special checking by the privileged program, it's easy to get it to do insecure things by messing with its config file. And half of all files in Mac OSX seem to be config files, many of them writable by admin.
Oh, HERE'S a good one, ANYONE can write to /Library/Caches - which means that if an application that uses it doesn't validate what's in the cache, you could probably compromise it.
How about putting stuff in /Library/StartupItems (not writable by admin, but it can be deleted and recreated, and the system will run stuff in it as root at next restart). 10.4, they've tightened security on this (if the item isn't owned by root or isn't read-only to other than owner, system startup will ask the user if they want to run it), and they've also put in a different mechanism which may also improve security there.
The fact is, admin can do things that can compromise the system with no further authentication, and there is NO good reason to actually be running as that user except when doing administrative stuff (installing/removing programs, updating the system), and with fast user switching, there's no drawback at all to not running as an administrator.
I haven't had any problems with it checking, but trying to download updates, without installing, as a non-admin IS a problem (and if you have it set to "automatically download in the background", that's what it is probably doing). It doesn't ask for privileges, but after it finishes downloading it tries to expand it into a directory that requires group admin. Telling it to install asks for privileges first, and then the expansion works. One of the very few places where things don't work correctly as non-admin (again, this is in 10.3, I don't know if they've fixed it in 10.4).
It also doesn't remember if you've downloaded but not installed, once you leave the Software Update program, which is really stupid. In fact, it should check to see if the updates being requested are in the Packages directory already, whether or not it thinks it has downloaded it (and verify it against the checksum from the server). That way, if you are doing a re-install, it doesn't need to re-download things you already have. It would also be nice if it kept enough information to be able to re-update your system from downloaded packages automatically without needing to go to the server at all - i.e. keep track of which packages that you've kept are current, and in which order things need to be installed, to bring everything back to current.
All of the applications in /Applications are writable by group admin. That's a huge security problem.
/Library and a lot of stuff underneath it is writable by group admin. That's Internet plug-ins, printers, trusted certificates, help files, scripts, some frameworks, stuff in Application Support - a lot of stuff points things at executables, or has scripting capabilities, or is otherwise assumed to be trusted.
Much of the stuff in /Developer is writable by admin. That means something could do a sneak attack, so anything you build and distribute is a virus vector.
There is absolutely no reason to run as an administrator, except to do installations (you can do installations as a non-administrator, but ownership of installed files seems to be cleaner if you always do it from one login, and then the same principle applies - if you do it using your normal login, then some things will be owned by you which means they are vulnerable).
With user switching enabled, there's even less reason to run as an administrator, since you can easily switch back and forth. Even for sudo, all you need to do in a terminal window is su to your admin login first, then you can sudo to your heart's content.
Isn't that what I said? NTP does it incorrectly, but the underlying protocol can be easily adapted to a none-broken implementation. There's nothing about NTP that says anything other than ntpd has to care about what the current NTP timestamp is, not even the kernel, and certainly not user programs.
In 10.3, the group for /Applications is admin, so only user accounts that are set to be Administrators can install or remove applications. Maybe they changed this in Tiger. All of the applications I looked at are also modifiable by group admin. That's why I tell people that they should set up an administrator account, and disable it for themselves. The obvious user name, admin, is blocked by Apple's account administration routines, though (you can create it as your initial user in 10.3, but they stopped that in 10.4). Yes, normally you get a group created that is the same as your user name, but it went ahead and used "staff" instead. I suppose it is a good idea not to have something obvious as your admin account, though.
There are very few things that you need to actually be logged in as an administrator, and even fewer where you'd need to log in as root (usually easier to just open a terminal window and use su (if you've enabled the root password) or sudo).
I don't know about Microsoft Office, but the Office "Test Drive" behaves abominably with respect to admin rights. You basically have to install it and run it as an administrator, but the failure modes if you don't are not obviously because you're not running as the right user. Stupid stupid stupid.
Unless you have your keychain password set to something besides your login password, so it doesn't automatically unlock it when you log in, it shouldn't even ask you for your password then. My parents usually forget their password, since it is set to auto-login for them, except when I'm visiting and using the machine (and thus either logging them out, or using user switching, either of which requires they enter their password to get back on).
I wouldn't call 36K bytes over 1800 years a serious problem. By then, we'll need local-planetary-time adjusted from Galactic Time for different planets and speed-of-light and relativistic corrections anyway, they'd be thankful for a 36K solution.
Oh, yes, this is SO difficult:
and it is so difficult to add:I see why you think it is a serious problem.Why does it matter how many seconds it is until July 5, 2009 at 5:31:05 UTC? If the number of seconds matters, state it as number of seconds. If the correct local time matters, state it as a local time (heck, you don't even know for sure if DST will be in effect or not). If you're trying to pre-program a telescope, you'll have no idea of the exact correction until that day, anyway.
I do see one potential problem, and that is storing future dates (i.e. reminders/alarms) as a Unix seconds-from-epoch value. In that case, you are indeed better off storing things as uncorrected values, i.e. each day is exactly 86,400 seconds long. BSD (or at least, the man pages on OSX indicate) a function time2posix() and posix2time(), which accounts for this difference (POSIX basically requires time values to not have leap-seconds added in, which means the system clock has to stop for 1 second at a leap second, and the actual number of seconds (as a time interval) since Jan 1 1970 is off from the time value returned by time() by the number of leap seconds since then).
They basically are proposing to use TAI as the legally defined time for things like transactions, date changes, etc. TAI would become the "official time" instead of UTC (of course, contracts and such would still generally refer to local time, which would be TAI corrected for timezone).
It doesn't solve anything.
I have two clocks that use 60Hz to tell time. They stay exactly in synch, but vary from NTP/WWV time by a varying amount each day (the frequency drifts slightly, but is corrected so the right number of cycles (5,184,000 = 60 * 86,400) occurs for each day. I believe they do NOT ever try to insert leap seconds, that's a function of whatever is converting interval timing into time-of-day.
You can't maintain a highly accurate clock without external synchronization. Why doesn't your external synchronization source include leap-second information (including when the next one is going to occur, as soon as it is known)? It's no more error prone than having the clock data itself be wrong.
The application itself should be tested against leap-seconds, there's no reason you should have to test to see if a particular leap-second is going to cause a problem (just as you don't have to test it for each time the clock rolls over from 23:59:59 to 00:00:00). You add ONE LINE to a leap-second file, if you did it right, or just let NTP do it for you if you did it even more correctly.
Note that the NTP epoch implementation is itself arguably done incorrectly. A reasonable kernel can handle it better by having the NTP daemon update a leap-second file, keep a fixed Unix epoch and correct to UTC in the libraries while keeping a constantly running clock going.
Because it is really easy to simply have a flag saying "at the end of this day, the last minute will have 61 seconds in it, going from 0 to 60 instead of 0 to 59." Most clocks don't need to be so precise that they have to even deal with that, they'll just re-synch with the new corrected time. DST is much more disruptive, and there's a fine mechanism to handle it in the computer world (or, at least, ones with decent operating systems).
NTP has provisions for it, standard Unix time libraries have provisions for it, or you can ignore it since your clock is probably off by 2 or 3 minutes anyway. If you need to be precise to the sub-second, you already have the mechanism in place to automatically deal with it.
The accumulated leap-second field is also being used in GPS units to distinguish between different 1024-week periods (there are around 12-13 leap seconds in a 1024 week period, so it can be pretty fuzzy and still usable for a couple hundred years after their manufacture date, even if it changes to 10-11 or 14-15 leap seconds in that 1024-week period).
There is no mechanism in place to handle a 10-second or 1-hour leap - and they won't be tested for real for a long period of time. If you think Y2K was bad (in terms of expenses to go through all code, in terms of the panic and consternation it caused), wait until Leap Hour hits. The leap-second mechanism gets tested currently every 18 months or so, and again most equipment is so imprecise it just doesn't care if it is 39 seconds fast or 40 seconds fast; and anything that does care already has the ability to do it easily and correctly.
X is about as well integrated as it can be. I'm not sure how you think it should work differently.
And Linux already runs just fine on Apple hardware, switching to x86 isn't going to make much of a difference there.
When the "World Wide Web" came out of CERN in 1990, it was little more than an obscure research channel until the development of Mosaic. This was done at the University of Illinois. If you don't know where the University of Illinois is, I'll give you a hint. Start looking in the United States.
Honestly, some people have no sense of history. Everything is built on everything else. HTML and HTTP are built on other similar protocols and formats. There was Gopher, there was SGML, there was Ted Nelson's Xanadu and hypertext and hyperlinks. There were already search engines (Archie and Veronica). What we ended up with is certainly not the best we could have had.
l12n? If you must use stupid "omitted letter" abbreviations (i18n was cute, but stupid), at least count the letters correctly! There's i18n (internationalization), l12y (localizability), g11n (globalization), and l10n (localization). Not l12n. Maybe l14n, that would be localizabilition, if you're George Bush.
First, you'd do better panhandling. You're making $60 (€50)/week, I'm sure you could get more then $10/day in change (or even picking up aluminum cans, if they do recycling there).
Second, I don't know what you think he meant by "top of the line Mac G5", but either you go all the way (16GB ECC RAM, 1 TB disk, dual 30" cinema displays (and the QUADRO FX 4500 card to drive them) , Bluetooth/Airport, modem, Wireless keyboard, Fibre Channel Card, OSX Server, Applecare), coming out to about €23,000 each, or go with what he probably meant, which is a reasonably decked out machine, which would currently be the Quad (dual dual-core) 2.5GHz machine, base price of $3,299, boost to 4GB ECC, 500GB disk and add Airport/Bluetooth for about another $1,800, or about €13,000 for 3 of them. Now, that's probably a bit of an exaggeration, or he took an awfully long time putting a system together, or he gets paid so much that his finances aren't really applicable to "most people", not just student types working for a pittance. But that's one hell of a lot of system for about €4,300 ($5,100). If he wasn't quite so pushy about "top of the line", three dual-core 2.3GHz with 1GB/250GB comes out to about €6,800 ($8,100). At $200/hr, he'd only need to spend 40 hours researching, ordering, putting together, testing, sending back and re-ordering (including calling customer support), re-installing operating systems a few times, etc. Note: all prices are from US Apple Store, I realize that prices in Europe are a bit higher, especially with the VAT added on.
Or did you mean to say 13,000 Euros instead of 33,000?
As you say, you're a poor student, and you can't afford a good computer. It doesn't surprise me that you can't afford a Mac yet.
So you moved the condition that you're actually checking to the end of the loop (and you forgot to initialize "data_left_to_process", but let's assume it is set to "true" to begin with - but what if it isn't true?). So wouldn't it make more sense to use an explicit do {} while (check_for_more_data())? Except that would reveal the major bug you've introduced which is that it will fail if there's no data at the beginning.
In addition, you haven't indicated what happens if "valid_preamble()" returns false - how does "valid_data()" handle an uninitialized "data" variable? Or are you omitting a bunch of nested if conditions? How is that more clear?
If you're holding that up as an example of not "poorly written code", you've failed. I can embed exit conditions in variables that get set in hundreds of lines of code just as easily as I can embed breaks and continues, you'll still have to search for it. The problem is a loop that covers hundreds of lines of code, not where in the loop the exit condition is determined. You're going to have to read the code anyway if you want to know what it does, knowing the loop exit conditions at the beginning of the loop is the least of your worries (unless the loop exit condition can actually BE determined at the beginning of the loop, in which case it probably IS a simple loop). What you're doing is making it more complicated in the name of simplifying it. If it is a complicated loop, it will have complicated exit conditions.
Using break and continue and return appropriately is in no way "poor coding technique", and if you think that you shouldn't use break because "it can be proven that it isn't absolutely necessary", I suggest you start doing all your coding in Brainfuck or some other Turing tarpit.
I consider for (;;) to be slightly more aesthetic than while (1) (as even the trivial logical expression "1" doesn't have to be optimized away).
Which is why the "last mile" owners should only be providing connectivity to connect to the consumer's ISP of choice, on an equal footing with any other ISP, including any owned by or operating for the benefit of those owners. Charge a fair price for the connection, and compete on the basis of service and offerings as an ISP. The ISP shouldn't be able to get away with poor service on the basis of getting favored status from a natural monopoly. Even where there are two competing providers (e.g. cable and telephone), that isn't enough of a free market to keep prices fair. Perhaps with the addition of power-line and Wi-Max (satellite isn't a competitor, people only use it when it is the ONLY option offered), there will be enough competition to start making it a free market, but even with those, it is still a limited natural monopoly - there's only so many towers and cables and lines that can be strung around a town, so early providers get a lock and then can keep prices artificially high, even without collaboration. You can't have a free market when the "barrier to entry" is so high, so regulation is necessary. I wish the FCC would start providing that regulation.
There's nothing magic about using LEDs as the light source to excite the quantum dots. Use a standard fluorescent bulb, except use quantum dots instead of whatever phosphor is normally used (different ones produce different spectrums, which is how you get "warm white" vs "cool white" vs "natural" vs "grow lights", etc). These would just be a wider-band spectrum "natural" than current phosphors can do.
The eye can adjust to color temperatures quite well. What the CRI measures is the completeness of the spectrum, not the temperature. The color temperature is based on only the summed effect of the different frequencies. You can have vastly different spectrums that result in the same color temperature, for example in a television where only three different fairly narrow bands are used to produce a wide range of colors.
Two problems with using such narrow bands is that different people have different frequency sensitivities, so an image that looks correct for one person won't look "natural" for another (I've often wondered how effective going to a 5 or more band system would be for television); and that something that has its own narrow bands of reflected color that don't match the bands of incident light will look different than it would in "true" white light (of whatever color temperature).
With quantum dots effectively spreading the bandwidth of the light source into a wide spectrum light (which is not a new idea; I'm not sure why this is being considered a revolutionary new discovery, unless they were using novel techniques to produce the right mix of the right sizes), you could use any other low-power light source, not just LEDs. LEDs are convenient for some things because they can be used at very low power and last a long time. Where you need more light, you could use quantum dots with low-pressure sodium, for example, or conventional fluorescent bulbs except using quantum dots with a wide spectrum to do the fluorescing. The article also mentioned but didn't expand on using direct excitation with electricity to get quantum dots to give off light, which could be even more efficient.
(oops, sorry - the second blockquote was dated July 21, 2005, referring to a report from Jupiter Reports, as reported in Macworld.
People sure have short memories. Not long ago, all the articles were about "beleaguered Apple". I guess that was because, back then, all the journalists were using Windows machines, right? The difference now is that Apple somehow convinced them all to switch using underhanded techniques like making good computers.
And, while business use is increasing, I'm not sure what percentage of the market shares are for personal vs. business use:
but I believe that personal use is significantly higher than business use for Macs, and significantly higher for business use than personal for Dell, meaning that the percentage of PEOPLE who are more interested in what Apple is doing compared to what Dell is doing is a lot higher than what you think.I personally am excited to see new products out of Apple. The new Power Macs and Powerbooks are more exciting to me than the announcements about new iPods (video or otherwise) or the new iMacs, even though those show more the direction Apple might be headed. It shows that Apple has not yet abandoned the PPC market, that current products really will be supported for some time to come despite a transition to Intel processors.
BTW, for anyone who is positive that Apple will stop using PPC processors by the end of 2007 should remember that Steve Jobs denied the possibility of a video iPod right up until he announced it. If IBM is producing chips in 2007 that meet needs of Apple customers, there's no reason for Apple to stop using them simply because in 2005 they said they would. They still have to deal with getting developers to produce 64-bit native Intel code , which is much less of a problem on the PPC architecture (since PPC-32 is a subset of PPC-64). With the x86-64, you get more improvement in performance than simply increasing register size and address space (which, depending on the application, might not get you much if anything). With PPC, if there's no need to go to 64 bit, then there's no performance penalty for not making the move. For low power stuff (e.g. laptops, Mac Mini), the Intel line will probably do fine. For high performance, they may find that upcoming IBM chips continue to make sense.
"They plug in and go" and "behave how you expect" - what part of that is "not as useful or versatile out-of-the-box"? Are you comparing it to the packages available with a typical Linux installation? You realize that, for about the same amount of effort of doing that initial Linux installation, you can install pretty much all of those on a Mac (of what isn't already installed by default). Otherwise, what can't it do out-of-the-box that you think it should be able to do?
The alternative to PDF for most people is to send Microsoft Word documents. PDF is much better.
I really prefer PDFs, at least for "reading a manual" (or "reading a novel"). I think the problem is Adobe Reader, not the PDF format. I usually use Preview for reading PDFs. I have a screen that rotates (though I don't have a driver for Mac OSX that flips the display); with Preview, I just rotate the view, then go to full screen, and it's much easier to read than most HTML on-line documents. I don't even need to do the screen flip when reading it on a 20" iMac G5. If I want to search, I just search right there, I don't have to somehow do a search over the set of different pages that the HTML doc is organized in (if I'm even given the option).
I often want to have the whole thing in a fixed form, not subject to random server crashes, Internet problems, or someone deciding to remove the content. I can download a PDF as one file, I don't have to either try to grab all the pages, or hope that the web site has a tarred or zipped version I can download (and then find the "index.html" page in the middle of all of it to start up in). I'll often save a web page where I want the content (as opposed to links) as a PDF (e.g. Print to a PDF). Only thing I'm missing is ability to print additional files to the end of what I just saved.
The only time scrolling is a chore for me is when I don't have a decent screen, and the document is done in two (or more) columns. Of course, a web page organized the same way would be just as bad.
I really prefer PDFs. I think the problem is Adobe Reader, not the PDF format. I usually use Preview for reading PDFs. I have a screen that rotates (though I don't have a driver for Mac OSX that flips the display); with Preview, I just rotate the view, then go to full screen, and it's much easier to read than most HTML on-line documents. If I want to search, I just search right there, I don't have to somehow do a search over the set of different pages that the HTML doc is organized in (if I'm even given the option). I can download the whole thing as one file, I don't have to either try to grab all the pages, or hope that the web site has a tarred or zipped version I can download (and then find the "index.html" page in the middle of all of it to start up in). I don't even need to do the screen flip when reading it on a 20" iMac G5.
The only time scrolling is a chore for me is when I don't have a decent screen, and the document is done in two (or more) columns. Of course, a web page organized the same way would be just as bad.
iMac G5 (1.8GHz, 512MB): 15 seconds to shutdown, 50 seconds to boot (inluding auto-login, dock, menu bar and desktop files displayed, at which point system is usuable), 55 seconds to restart (shutdown and boot, minus hardware POST), 7 seconds to sleep (until the disk spins down), slightly less than 5 seconds to unsleep (including wireless/DHCP negotiation).
The obvious way to do fast booting is to complete initializations and snapshot memory. On reboot, device drivers have to verify their devices are still connected and re-initialize them, system time needs to be updated, network connection needs to be re-established, and system should be ready to go. Load time from disk is minimal, but you still have to wait for spin-up and init, so storing the post-config memory image in flash makes more sense - by the time the disk has spun up, the OS is ready to go. The big speed-up comes from not scanning for devices, just assuming that the config hasn't changed, verify devices are there, and initialize them to known state. OS has to handle new devices, new busses, new cards while it is up (i.e. everything is a loadable module). Sleeping/hibernation then is just a variant on the theme (boot basic OS from flash, initialize devices, re-load active processes which are written out to disk). The fun part is figuring out if anything has changed while the OS has been suspended.