Another bit of information. Just in case the version of the development tools is a contributing factor, the software I am using is 10.3.8 and Xcode 1.5
I have already submitted test results and other followup information to the author of the driver.
Public thanks are deserved by the author. He did a nice job. I enjoy the functionality and appreciate his effort.
1. I configured the source to build for only XY support. 2. I ensured that my newly built driver and the preconfigured driver each had appropriate permissions. (root:wheel). 3. I wrote a script which unloaded the system version of the driver and loaded either the prebuilt or the newly compiled driver based on an argument.
results: Each time, the prebuilt dirver would panic the host and require a hard reboot. Note that this was immediate, and did not require me to touch the trackpad to trigger the failure.
Conclusion, since 10.3.8 was so recently released the developer probably did not know to rebuild the pre-compiled distributions. If you have already installed it, and are running 10.3.7, you may be at risk when upgrade to 10.3.8. Either upgrade from source now, or revert to the stock driver and wait for new binary packages.
The freshly built driver appears to work as advertised.
Test system: 1 GHz Aluminum 17" powerbook with 1GB memory. OS, stock 10.3.8 with no third party drivers installed.
I have an aluminum powerbook which according to the web site is supported. I am running Macos X 10.3.8.
I followed the instructions for installing the XY based driver temporarily. Immediately upon loading the new driver the system dims the screen and instructs the user to do a hard power down and restart the machine.
I will investigate further. For now, be very careful, and those for whom it does work should post explicit information on their software+hardware configuration so as not to mislead others.
Your choice of words is revealing. They speak directly to the geek mindset I described in my earlier post. They reveal a subtle trap that we create for ourselves by thinking about the problem domain from our own narrow perspective. Programmers who view the problem through the filter of domain specific knowledge often fall into this trap.
Yes, but how much more can the developers dumb it down for the more technically challenged users without making it utterly useless for the less technically challenged.
Your use of the phrase "technically challenged" indicates that you are thinking about the problem in terms of technical knowledge. Additionally, your mention of a possible solution, "dumb it down", is telling. Together, these reveal that you are looking at design from a peculiar perspective. I call it peculiar because it is so prevalent despite the fact that it appears not to be very useful.
Program design and interface design is a form of communication. The relative success or failure of a message in any medium is measured by its effect on the recipient. Does it convey the intended message readily? In what ways can it be misinterpreted? Is the message a pleasant experience? Enjoyment, senses of understanding or accomplishment, boredom, confusion, or frustration are subjective and often ignored by geek designers. However, they are perhaps the only real measures of worth as measured by users. These subjective experiences are the only tangible effect (outside of the computer) of the program in the real world.
So, do not "dumb things down". Is the "knowledge" you require of your users inherent to the real world problem domain and all possible solutions? Do your users commonly misunderstand the concepts and thus fail to use the program effectively? If yes, your job as a designer is to redefine your presentation in order to make this information discoverable and teach the user as they use the program. Another possibility is that the information required of your users is not useful to them. In this case, it is often possible to find features in the problem domain which users readily recognize with very low rate of misunderstanding. In this case you may restructure your interface to decouple the arcane solutions from the tangible, easily recognizable problems.
Simplicity does not involve "dumbing things down" it involves rethinking the problem to make the problems and solutions recognizable and discoverable to your intended user. Failure to do so is the designers fault. They have communicated poorly to their audience. If information is absolutely required they have failed to inform their users in ways they readily apprehend. If information is an arbitrary requirement (imposed by the designer for self serving reasons such as laziness), it reflects needless complexity.
People are intelligent, resourceful, and capable of learning new things. They enjoy mastering new things, but typically only when this is both interesting and relevant to them. If you do a good job as a designer you play into your users strengths, leverage their existing knowledge and abilities, and convey new knowledge in ways that they will readily and eagerly apprehend. If you do this job poorly, you will only confuse and frustrate them.
Simplicity need not be stupid or confining. It can be elegant and support complex domains. Great designs lets users employ their intelligence and existing knowledge towards solution of a problem, and expands their knowledge when required. Poor design forces users to apprehend the intention of the developer's conception of a problem, even when this singular viewpoint is not very powerful or useful to them.
Bingo, the problem isn't Windows, its Windows Users.
Really, this stance strikes me as the antithesis of the problem. It is programmers who bear the blame here. I'm not singling out Microsoft programmers (despite the large and tempting target they present). I'm talking about most people who write system software or applications for general use.
Here on slashdot, we are predominantly geeks. We enjoy technology and learning about technology. In some cases, a large minority of us mistake our interests in these as evidence that these activities are somehow inherently important. Those who do so gain certain psychological and social pleasure from this knowledge and interest. This is part of being human. We consider ourselves special and important.
Computers and software are marketed to and used by the general public. People, being people, think that their interests and their knowledge is important. Learning about hardware/software/security, etc. is not interesting to them, therefor the fact that they tend not to spend time doing so should come as a great surprise. Geeks tend to see this lack of interest as evidence of a problem (and at times as an affront to their own sense of self worth). This seems a rather shallow and unproductive view. Human beings focus on those things that interest them. Pleading with them to attend to things we think are important, or looking down on them for this lack of interest, is a fruitless path.
The problem is not users. The problem is that we have created hardware and software which does not adequately match the needs of the users. Software should match the requirements of its users not require them to change their typical behaviors to meet the needs of the software.
Some people are destructive and malicious. Well designed software takes this into account, and provides authorized users with reasonable protection from those who would try to harm them. Well designed software behaves in consistent and predictable ways so that users of varying levels of experience, knowledge or interest can benefit from its use.
Software should be designed for the people who will use it. Most programs suck, because they are designed for a particular business goal, or designed by geeks based on their own knowledge of how they would like to use it. It is no wonder, that most software leaves the average person cold. It is arcane, inconsistent, and requires too much knowledge. Users are not stupid. They are not lacking in intelligence or ability. They are lacking in a sense of enjoyment and sufficient interest to use software the way the geeks designers intend.
Great software takes its users interests and expectations into account. Great developers strive to understand users and write software which serves them.
So, we are the problem, not the users. Blaming people for their own human nature is not the way to go here. Projecting our own failures of understanding onto the users is a misguided attempt to pass the buck.
Believe it or not, a lot of us are running Windows 2k/XP without these problems.
I believe you. Large numbers of users are not affected by these problems. However, a large percentage of users are adversely affected. Your experience appears to be atypical.
Yes, I'm not using IE. Yes, I'm not using Outlook Express. Yes, I'm behind a firewall. I'm not claiming to be 100% secure, but buying a Mac or switching to Linux would do little to improve my computing experience. Never mind the stuff I wouldn't be able to do because I use software that isn't 100% supported.
How ironic. You describe the safety of your current environment, and dismiss alternatives using identical criteria. You claim that an alternative to windows would not improve your situation, and support this claim by alluding to things which you could no longer do (presumably because you rely on programs which exist only on Windows.) What's ironic is that you do so after implying that you owe part of your safety not running several other programs.
So, you are comparatively safe, and content with your environment. Good for you, I do not begrudge you that. However, your statements strike me as disingenuous. You blithely gloss over the fact that there are already things you cannot do (programs you cannot run) just to remain safer in your chosen environment.
Call me old fashioned, but something is terribly wrong when a user cannot use the software bundled with their system, in the way it was intended to be used, without compromising the safety or performance of the system. Computers should serve their users. They should not break or degrade because the user actually runs the software as intended by the designers.
Your anecdotal evidence suggests that you are not as cozy as you claim. A wider view of the situation suggests that your reported condition is far from the general case.
A recent study commissioned by AOL and the National Cyber Security Alliance (NCSA), suggested that the majority of home users are adversely affected by spyware and other malware.
The NSCA is supported by the Homeland Security Department and the FTC. It is also supported by a large number of tech corporations with either financial or political lobbying interest in computer security: the board of directors includes representatives from Cisco, Symantec, RSA Security, McAfee, Microsoft, and Bell South.
This group strikes me is far from impartial, as each member (public or private) has significant interest in publicizing (or magnifying) certain security risks. These vested interests should suggest we take the report with a grain of salt. Despite this, the results are quite interesting.
They polled a random sample of (PC using) AOL subscribers and also gained access to their computers to inspect them for viruses and malware. They found that:
77% considered themselves safe from threats. 66% had been infected with a virus in the past. 20% were currently infected with viruses. 80% were currently infected by spyware (averaging 93 sypwares/host) 89% of owners with infected PCs were unaware of these conditions.
The survey's margin of error was +/- 5.4%
These are home users, business users, and highly technical users are sure to be better protected on average.
Despite this, the protection of businesses comes at very high costs measured in hardware/software/wages/training. Sophisticated home users also spend additional time and/or money protecting themselves.
Here are links to pdf files containing a press release and summary of the raw data.
Seriously though, if anyone knows how to tell clearcase to ignore whitespace for diffs, that would be fantastic. We've had a few people look at that but no luck.
I sympathize with your plight, but treating whitespace as significant has a number of benefits.
For instance consider Python, whose control flow structure is defined by whitespace alone. White space which is mere ornamentation in some contexts is critical in others. For rigor and consistency the only sound approach is to consider each byte significant.
The bottom line is that currently spyware is only a problem on Windows. Thus, running any viable alternative to Windows is the most effective way of avoiding spyware at the moment.
Running a GNU Linux distro, any of the BSDs, or Macos X are all viable options, and arguably the most efficient solution to the problem of spyware.
Granted, many might find these options unsuitable for a variety of reasons. However, labeling that suggestion a Troll does not make it untrue. Wasting time and CPU to either spyware or anti-spyware software both seem objectionable. Systems which provide desired functionality, and do not require additional effort to continue functioning normally are a sensible choice for many.
you'll suddenly get 100,000 hits in a day in which case you'll crash it
Wanna, bet?
I did some tests a couple of years ago on an ancient (1997ish?) beige G3 running Macos X. Hammering on a mysql+php+apache based web app, did bring system performance to a crawl, and caused the majority of requests to timeout and fail. However, it did not crash once.
I know that I will never have any mod points. Please either mod me down, or retro-presoon drop me an email so I will have avoided submitting that embarrassing post.
It's really a neon sign on Frogstar World B announcing the construction of a restaurant to be constructed on this location in several billion years and reservations are welcome.
Such a sign would not make any sense.
Obviously the restaurant willon forewhen constructed already.
Re:Why don't they partner with IMDB?
on
TiVo to Offer SDK
·
· Score: 1
Yes, but not as thoroughly as via an imdb search.
Wishlist->actor
You can see if anything is showing soon, or even record items in the the wish list when they arrive in the future.
imdb integration would provide more information.
However, there is no revenue from such a partnership. Therefore, I neither expect, nor wish for Tivo to waste time and money on this.
This is something that should be left for independent developers. I don't have 7.1 yet, so have yet to actually use the third party API they've recently released on sourceforge. My guess, however, is that something like that will have to wait for a later release of the Tivo development kit.
Don't get me wrong, air breathing is the best approach for the long term. The majority of fuel and oxidizer for a launch from sea level to orbital velocity occurs within the atmosphere. Thus, reducing oxidizer payload is an enormous win.
However, the current need is to have a man rated crew carrying vehicle on line in under a decade. Neither scramjets or new shuttle-like designs appear well suited to reach this immediate objective.
Hypersonic air breathing vehicles are not viable in the short term. Scram jets, for instance, in small prototype vehicles have burn times measured in seconds not minutes.
With the demise of the shuttle, relying on exotic technologies is a bad plan. We need simple, reliable tech as soon as possible. Space planes are not the answer to that.
There are a number or really crappy USB network adapters out there. I've had very good luck with both D-Link and Belkin adapters with Tivo, but mileage varies. If you continue to have intermittent problems, and consider replacing the network adapter you might want to search the tivo community forum for recommendations.
Currently Tivo can only use USB 1.1 speeds to access the network. Under the upcoming release of the software, some network interfaces will be supported via USB 2.0 drivers enabling much faster network performance for both wired and wireless connections. If you decide to replace the network interface, it makes sense to choose one which has a supported USB2.0 driver.
Do some google searches or search the tivo community forum for info on this.
For the past 4 weeks or so Tivo has been rolling out the next major release of the OS. I'd bet they are deploying several hundred to a thousand per night. I live on the east coast, and have had no connection issues on any of my Tivos. I know this because I check them once every evening to see whether I've gotten the upgrade yet. (I got on the expedited upgrade list weeks ago.)
Just out of curiosity, are you failing to connect at all (not getting the clock set)? Or, are you failing far later.
Manually, connecting and watching the progress (which takes a matter of minutes on a fast link) should narrow it down.
It is possible that your Tivos are trying to connect during peak night time periods when OS downloads are happening.
Perhaps, you are timing out during download of the new OS yourself. And this is causing the failure.
Re:Why don't they partner with IMDB?
on
TiVo to Offer SDK
·
· Score: 1
Well the basic listing information already contains the information about whether it is new or a rerun.
Also, most networks submit additional listing information which is available locally on the tivo by hitting the "info" button from the episode screen. This information includes full credits for actors, director, etc., the original air date (when it was first released), episode number (e.g. 306 - season 3 episode 6).
So, the imdb hooks would only work for shows for which the network provides a full field set when they report to the listing integrator. All that information on an episode can already be viewed on the Tivo without making a network access.
I like the idea of keeping a persistent log of what episodes you have seen. However, the Tivo has very little memory, and disk access is precious since it already needs to do its index housekeeping, inter-Tivo networking etc., while recording one show in real-time (2 on a directivo) and playing back another.
In short, this doesn't sound worth any additional effort.
Of course it won't fix your negotiation problems because its a problem with your network, not theirs.
If you are connecting via a telephone line, you probably should look at your telephone wiring, and other devices connected to it. Perhaps you've got a device that changes the amount of power on the telephone line when your tivo attempts to make a call, or you try to use the phone often when when the tivo is thinking of calling. In that case it politely drops its attempt and waits another day.
If you are on a wired or wireless ethernet, check signal strength, and cabling.
Bottom line Tivo makes connection via TCP/IP. It used ppp over a POTS line, or vanilla IP over ethernet. None of my 3 Tivos have ever had a (failed negotiation) during the past 3-4 years. (2 via wired ethernet or phone line, 1 via phone line).
Display postscript was an official language distribution from adobe. In the late 80s early 90s it was developed as a serious contender to the X10/X11 display model. Many people confuse Display Postscript (hereafter called DPS) with other postscript related implementations.
NeWS (the Network Extensible Windowing System) was an independent implementation of postscript. It used a complete different set of objects to model display objects and handle events. It was similar in general flavor and purpose to DPS, but its major shortcomings were that it did not accept postcript type 1 fonts, and it was incompatible in a number of minor ways that meant that much output destined for HP printers (which used real postscript) did not render properly under NeWS.
Some people on the GNUStep team had been developing a display Ghostscript engine. Note that Ghostscript and postscript are independently developed engines. Thus when adobe dropped support for DPS it had no effect on that project.
I have not looked at GNUStep in several years, so am not intimately familiar with the details, but searching google today seems to indicate that that a native Display Ghostscript (DGS) system is no longer under development. Also, I note that an attempt to implement DPS as an extension to XFree86 also died about 4 years ago. So, my guess (and it is just a guess) is that DPS as a windowing system is a dead language.
I believe that GNUStep developers, instead, split the GUI layer into back end and front end parts. The actual GNUStep libraries that accept postscript fragments in display calls would then call either vanilla ghostscript to create a bitmap which would then be rendered using X11, or perhaps rendered via some other X11 rendering library that understands a subset of the postscript language. In any case, the interpretation of postscript fragments would be passed to an X11 based back end, and the windows, mouse events etc. would also be managed by X11. In real DPS these events were accepted by a small C base core, and the passed to objects running in the DPS interpreter. This is a significantly different model than GNUSTep appears to be using.
So I don't consider GNUStep dead, but do consider DPS dead.
DPS was an interpreter which managed display contexts for a system. It was a set of OO extensions to postscript. Basically one of the underlying types in postscript was a dictionary, an associative array like storage structure. Each window, menu, click-region, etc, was a an object whose members (and methods) were stored by name in dictionaries.
An interesting offshoot of this was that the real semantic guts of both news and dps was a postcript file. Adventurous users (or crazy, your call) could tweak certain aspects of appearance or behavior system wide. I briefly experimented with sloppy focus by tweaking the dps source code back in NeXTStep 1.x days.
Anyway, in the early Rhapsody days, Adobe set such high license fees for continuing to allow DPS use by NeXT/Apple, that Apple chose to stop using it. Since PDF supports a subset of PostScript, they decided to go that route instead. Most people I spoke to, agreed that it looked like the license fees were good evidence that Adobe wanted to drop DPS entirely and that their choice of pricing forced Apple's hand.
In the end, I feel that Apple made the right choice. It automatically meant that remote display protocols for Macos X would take a hit. However, it meant that local display performance would dramatically increase. Since that affects far more people, they made the most sensible choice.
Sorry that I was not able go give a very coherent answer here. This is ancient history. I hope you found it useful anyway.
if I find that a Linux, NetBSD or FreeBSD machine takes some 5 minutes to mount an NFS share on an OS X machine (with portmap running on all nodes) then I think that is reasonably good evidence that there's something wrong with the OS X implementation.
You are mistaken. Those symptoms are evidence that you do not have dns set up properly. A long delay followed by a successful mount suggests that one or both of the systems is timing out on name service queries. Those symtoms are consistent with missing 'A' records, missing 'PTR' records or both.
As for configuration, on any of my BSD or Linux boxes, all I need is a single line in my/etc/exports files to make NFS happen. You cannot possibly make any informed claim that OS X makes it that simple.
You are correct that it requires more than adding a line to/etc/exports. But you imply that that is all you need on linux or bsd (which is false). Export via nfs on Macos X is identical to FreeBSD. 1. Add a line to/etc/exports 2. Send a hup signal to mountd (killall -1 mountd) Or reboot. How is that harder than BSD or linux? It is identical to BSDs. I admit that I'm guessing about the need to inform mountd to reload configurations on linux since I have not used it in 5 years.
To mount a remote volume manually you can use "connect to server" in the finder, or use mount from the command line. (This seems identical or easier than Linux depending on your approach).
To make volumes mount and unmount automatically, add a line to/etc/fstab like "host:rpath lpath nfs opts...,net -s 0 0". Use the text file, or use combinations of nidump and niload via the command line, or do it all graphically via netinfo or the shareware NFSManager.app from bresink.de.
The automount daemon adds a dynamic mount point for every fstab entry containing the 'net' option (this is equivalent to the 'mounts' domain in netinfo).
After restarting the automount daemon, or rebooting, when you refer to/Network/Servers/host/path..., via either the command line or the GUI, the remote drive will automatically be mounted, and after it has been idle for awhile will be automatically unmounted. If you wish you can create symbolic links to those paths anywhere you want. Traversing them will mount what is needed on demand.
Having administered dozens of Unices both commercial and free, I find that the various ways to get Macos X to work as an NFS client or server is either consistent with other unices, or nicer. Your sweeping claims that Macos X is broken merely reveal your ignorance of basic unix administration.
Don't get me wrong, client side NFS could be improved on Macos X. It handles manual mounts and automount(8) mounts flawlessly out of the box. My only complaint is that the port of amd (which comes bundled with the os for use by experts) is a bit sketchy when using complex map rules. I would prefer to use amd but ended up reverting to automount(8) about a year ago. I believe that Apple will eventually migrate from automount(8) to amd, but it is not ready for wide use yet.
Remote display made sense for display postscript in ways that no longer apply.
1. Instead of shipping bits around it would ship fragments of postcript code that when executed would produce the bits.
2. When asked to ship raw bits it was pretty slow.
3. For general purpose graphics the model was highly limiting because it basically drew into a dumb frame buffer which was blitted to the graphics card. Because of this it was never designed to use hardware acceleration.
4. Security was poor.
5. Adobe killed display postscript. Apple had to redesign a new display model from scratch. They chose pdf swince it incorporates a subset of postscript, though not the elements critical to making the old model work sell remotely.
The core graphics model in OSX now makes heavy use of hardware acceleration. Their is a fundamental tradeoff involved. You can have it fast, or you can have it remote. It made more sense to optimize for speed.
You can use and number of VNC clients and servers to run it remotely or use Apple's remote administration tool. These are relatively slow. Had they made remote windowing a priority it would have dramatically reduced their efficiency and speed for basic rendering.
The author had a good grasp of the high level architecture, but beyond that was clueless. His interpretation of the design is way off the mark.
He seemed astonished by the 1024 bit wide data paths. The Power family is design with cache fill lines of 128 bytes. So, for instance the G5 L2 cache already does fetches 128 bytes into cache for each main memory read.
Similarly all the talk about doing with cache and VM is bullshit. Instead of having each vector unit interfere with a shared cache as is done today, they've simply added smaller per ALU caches to the design, and complemented it with a device that is a souped up cache controller/MMU unit (the DMAC). The dmac apparently will be able to address both memory, and other hardware by having a virtual address layer, to enable reference to remote cell units as well as local physical hardware. The 64 MB of high speed rambus memory, may be all that is required for a PS3, but in a workstation implementation that memory is L3 cache.
Altivec currently has 32 vector registers. Each ALU as 128. It it highly likely that the core opcode architecture will remain similar. The most likely addition will be to add a few flow control instructions to the existing mix.
Altivec is already powerful but the biggest limiting factor is latency. Altivec can peform 1 instruction per clock on the G5, However the pipeline is 8 levels deep thus the overhead involved in fetching data, loading registers, performing a calculation among 1-3 registers, and getting a result is prohibitively expensive. However, if you can arrange to submit 8 calculations (or more) in rapid sequence, you can keep Altivac and the CPU busy and reap great benefits.
The beauty of Cell will be in proving the ALUs with a bit more autonomy (thought not much more, they are still basically vector units), and enabling the main CPU to keep doing useful work while a number of ALUs are cranking away. Other novel design features provide for communication and synchronization with other units via remote addressing and timing (that's what those realtime clock signals are all about).
This will be very fast, and very cheap. However, all the hand waving, and theorizing this guy does about both hardware and software reads like patent bullshit.
Slashdot Mirror
That trick will no longer work under this driver, since multiple points of contact are significant and are interpreted in a different way.
Another bit of information. Just in case the version of the development tools is a contributing factor, the software I am using is 10.3.8 and Xcode 1.5
I have already submitted test results and other followup information to the author of the driver.
Public thanks are deserved by the author. He did a nice job. I enjoy the functionality and appreciate his effort.
I ran a few tests.
1. I configured the source to build for only XY support.
2. I ensured that my newly built driver and the preconfigured driver each had appropriate permissions. (root:wheel).
3. I wrote a script which unloaded the system version of the driver and loaded either the prebuilt or the newly compiled driver based on an argument.
results:
Each time, the prebuilt dirver would panic the host and require a hard reboot. Note that this was immediate, and did not require me to touch the trackpad to trigger the failure.
Conclusion, since 10.3.8 was so recently released the developer probably did not know to rebuild the pre-compiled distributions.
If you have already installed it, and are running 10.3.7, you may be at risk when upgrade to 10.3.8. Either upgrade from source now, or revert to the stock driver and wait for new binary packages.
The freshly built driver appears to work as advertised.
Test system:
1 GHz Aluminum 17" powerbook with 1GB memory.
OS, stock 10.3.8 with no third party drivers installed.
It can crash some systems hard.
I have an aluminum powerbook which according to the web site is supported. I am running Macos X 10.3.8.
I followed the instructions for installing the XY based driver temporarily. Immediately upon loading the new driver the system dims the screen and instructs the user to do a hard power down and restart the machine.
I will investigate further. For now, be very careful, and those for whom it does work should post explicit information on their software+hardware configuration so as not to mislead others.
Pssst, your bias is unzipped.
Your choice of words is revealing. They speak directly to the geek mindset I described in my earlier post. They reveal a subtle trap that we create for ourselves by thinking about the problem domain from our own narrow perspective. Programmers who view the problem through the filter of domain specific knowledge often fall into this trap.
Yes, but how much more can the developers dumb it down for the more technically challenged users without making it utterly useless for the less technically challenged.
Your use of the phrase "technically challenged" indicates that you are thinking about the problem in terms of technical knowledge. Additionally, your mention of a possible solution, "dumb it down", is telling. Together, these reveal that you are looking at design from a peculiar perspective. I call it peculiar because it is so prevalent despite the fact that it appears not to be very useful.
Program design and interface design is a form of communication. The relative success or failure of a message in any medium is measured by its effect on the recipient. Does it convey the intended message readily? In what ways can it be misinterpreted? Is the message a pleasant experience? Enjoyment, senses of understanding or accomplishment, boredom, confusion, or frustration are subjective and often ignored by geek designers. However, they are perhaps the only real measures of worth as measured by users. These subjective experiences are the only tangible effect (outside of the computer) of the program in the real world.
So, do not "dumb things down". Is the "knowledge" you require of your users inherent to the real world problem domain and all possible solutions? Do your users commonly misunderstand the concepts and thus fail to use the program effectively? If yes, your job as a designer is to redefine your presentation in order to make this information discoverable and teach the user as they use the program. Another possibility is that the information required of your users is not useful to them. In this case, it is often possible to find features in the problem domain which users readily recognize with very low rate of misunderstanding. In this case you may restructure your interface to decouple the arcane solutions from the tangible, easily recognizable problems.
Simplicity does not involve "dumbing things down" it involves rethinking the problem to make the problems and solutions recognizable and discoverable to your intended user. Failure to do so is the designers fault. They have communicated poorly to their audience. If information is absolutely required they have failed to inform their users in ways they readily apprehend. If information is an arbitrary requirement (imposed by the designer for self serving reasons such as laziness), it reflects needless complexity.
People are intelligent, resourceful, and capable of learning new things. They enjoy mastering new things, but typically only when this is both interesting and relevant to them. If you do a good job as a designer you play into your users strengths, leverage their existing knowledge and abilities, and convey new knowledge in ways that they will readily and eagerly apprehend. If you do this job poorly, you will only confuse and frustrate them.
Simplicity need not be stupid or confining. It can be elegant and support complex domains. Great designs lets users employ their intelligence and existing knowledge towards solution of a problem, and expands their knowledge when required. Poor design forces users to apprehend the intention of the developer's conception of a problem, even when this singular viewpoint is not very powerful or useful to them.
I will play devil's advocate.
Bingo, the problem isn't Windows, its Windows Users.
Really, this stance strikes me as the antithesis of the problem. It is programmers who bear the blame here. I'm not singling out Microsoft programmers (despite the large and tempting target they present). I'm talking about most people who write system software or applications for general use.
Here on slashdot, we are predominantly geeks. We enjoy technology and learning about technology. In some cases, a large minority of us mistake our interests in these as evidence that these activities are somehow inherently important. Those who do so gain certain psychological and social pleasure from this knowledge and interest. This is part of being human. We consider ourselves special and important.
Computers and software are marketed to and used by the general public. People, being people, think that their interests and their knowledge is important. Learning about hardware/software/security, etc. is not interesting to them, therefor the fact that they tend not to spend time doing so should come as a great surprise. Geeks tend to see this lack of interest as evidence of a problem (and at times as an affront to their own sense of self worth). This seems a rather shallow and unproductive view. Human beings focus on those things that interest them. Pleading with them to attend to things we think are important, or looking down on them for this lack of interest, is a fruitless path.
The problem is not users. The problem is that we have created hardware and software which does not adequately match the needs of the users. Software should match the requirements of its users not require them to change their typical behaviors to meet the needs of the software.
Some people are destructive and malicious. Well designed software takes this into account, and provides authorized users with reasonable protection from those who would try to harm them. Well designed software behaves in consistent and predictable ways so that users of varying levels of experience, knowledge or interest can benefit from its use.
Software should be designed for the people who will use it. Most programs suck, because they are designed for a particular business goal, or designed by geeks based on their own knowledge of how they would like to use it. It is no wonder, that most software leaves the average person cold. It is arcane, inconsistent, and requires too much knowledge. Users are not stupid. They are not lacking in intelligence or ability. They are lacking in a sense of enjoyment and sufficient interest to use software the way the geeks designers intend.
Great software takes its users interests and expectations into account.
Great developers strive to understand users and write software which serves them.
So, we are the problem, not the users. Blaming people for their own human nature is not the way to go here. Projecting our own failures of understanding onto the users is a misguided attempt to pass the buck.
Believe it or not, a lot of us are running Windows 2k/XP without these problems.
I believe you. Large numbers of users are not affected by these problems. However, a large percentage of users are adversely affected. Your experience appears to be atypical.
Yes, I'm not using IE. Yes, I'm not using Outlook Express. Yes, I'm behind a firewall. I'm not claiming to be 100% secure, but buying a Mac or switching to Linux would do little to improve my computing experience. Never mind the stuff I wouldn't be able to do because I use software that isn't 100% supported.
How ironic. You describe the safety of your current environment, and dismiss alternatives using identical criteria. You claim that an alternative to windows would not improve your situation, and support this claim by alluding to things which you could no longer do (presumably because you rely on programs which exist only on Windows.) What's ironic is that you do so after implying that you owe part of your safety not running several other programs.
So, you are comparatively safe, and content with your environment. Good for you, I do not begrudge you that. However, your statements strike me as disingenuous. You blithely gloss over the fact that there are already things you cannot do (programs you cannot run) just to remain safer in your chosen environment.
Call me old fashioned, but something is terribly wrong when a user cannot use the software bundled with their system, in the way it was intended to be used, without compromising the safety or performance of the system. Computers should serve their users. They should not break or degrade because the user actually runs the software as intended by the designers.
Your anecdotal evidence suggests that you are not as cozy as you claim. A wider view of the situation suggests that your reported condition is far from the general case.
A recent study commissioned by AOL and the National Cyber Security Alliance (NCSA), suggested that the majority of home users are adversely affected by spyware and other malware.
The NSCA is supported by the Homeland Security Department and the FTC. It is also supported by a large number of tech corporations with either financial or political lobbying interest in computer security: the board of directors includes representatives from Cisco, Symantec, RSA Security, McAfee, Microsoft, and Bell South.
This group strikes me is far from impartial, as each member (public or private) has significant interest in publicizing (or magnifying) certain security risks. These vested interests should suggest we take the report with a grain of salt. Despite this, the results are quite interesting.
They polled a random sample of (PC using) AOL subscribers and also gained access to their computers to inspect them for viruses and malware. They found that:
77% considered themselves safe from threats.
66% had been infected with a virus in the past.
20% were currently infected with viruses.
80% were currently infected by spyware (averaging 93 sypwares/host)
89% of owners with infected PCs were unaware of these conditions.
The survey's margin of error was +/- 5.4%
These are home users, business users, and highly technical users are sure to be better protected on average.
Despite this, the protection of businesses comes at very high costs measured in hardware/software/wages/training. Sophisticated home users also spend additional time and/or money protecting themselves.
Here are links to pdf files containing a press release and summary of the raw data.
http://www.staysafeonline.info/news/NCSA-AOLIn-Ho
http://www.staysafeonline.info/news/safety_study_
Seriously though, if anyone knows how to tell clearcase to ignore whitespace for diffs, that would be fantastic. We've had a few people look at that but no luck.
I sympathize with your plight, but treating whitespace as significant has a number of benefits.
For instance consider Python, whose control flow structure is defined by whitespace alone. White space which is mere ornamentation in some contexts is critical in others. For rigor and consistency the only sound approach is to consider each byte significant.
The parent was moderated "Troll"?
Obviously it touched a nerve for somebody.
The bottom line is that currently spyware is only a problem on Windows. Thus, running any viable alternative to Windows is the most effective way of avoiding spyware at the moment.
Running a GNU Linux distro, any of the BSDs, or Macos X are all viable options, and arguably the most efficient solution to the problem of spyware.
Granted, many might find these options unsuitable for a variety of reasons. However, labeling that suggestion a Troll does not make it untrue. Wasting time and CPU to either spyware or anti-spyware software both seem objectionable. Systems which provide desired functionality, and do not require additional effort to continue functioning normally are a sensible choice for many.
you'll suddenly get 100,000 hits in a day in which case you'll crash it
Wanna, bet?
I did some tests a couple of years ago on an ancient (1997ish?) beige G3 running Macos X. Hammering on a mysql+php+apache based web app, did bring system performance to a crawl, and caused the majority of requests to timeout and fail. However, it did not crash once.
Yes, really.
I also prefer that locate.updatedb run regularly and that
certain log files be partitioned evenly on date boundaries.
However, these are clearly aspects of system functionality not system performance.
This means that for laptop users, often daily weekly and monthly cron tasks are sometimes not run for quite some time, degrading system performance.
That is a load of BS perpetuated by several authors of irrelevant and purposeless shareware to perform OSX maintenance.
The periodic subsystem jobs clear out and rotate old log files and rebuild the locate database. These have no impact on general system performance.
Equally silly is the advice to periodically removing cache files or dot files, or run scripts to "fix permissions" or redo prebinding,
You are correct. I apologize.
I know that I will never have any mod points.
Please either mod me down, or retro-presoon drop me an email so I will have avoided submitting that embarrassing post.
Thanks.
It's really a neon sign on Frogstar World B announcing the construction of a restaurant to be constructed on this location in several billion years and reservations are welcome.
Such a sign would not make any sense.
Obviously the restaurant willon forewhen constructed already.
Yes, but not as thoroughly as via an imdb search.
Wishlist->actor
You can see if anything is showing soon, or even record items in the the wish list when they arrive in the future.
imdb integration would provide more information.
However, there is no revenue from such a partnership.
Therefore, I neither expect, nor wish for Tivo to waste time and money on this.
This is something that should be left for independent developers. I don't have 7.1 yet, so have yet to actually use the third party API they've recently released on sourceforge. My guess, however, is that something like that will have to wait for a later release of the Tivo development kit.
Don't get me wrong, air breathing is the best approach for the long term. The majority of fuel and oxidizer for a launch from sea level to orbital velocity occurs within the atmosphere. Thus, reducing oxidizer payload is an enormous win.
However, the current need is to have a man rated crew carrying vehicle on line in under a decade. Neither scramjets or new shuttle-like designs appear well suited to reach this immediate objective.
Hypersonic air breathing vehicles are not viable in the short term. Scram jets, for instance, in small prototype vehicles have burn times measured in seconds not minutes.
With the demise of the shuttle, relying on exotic technologies is a bad plan. We need simple, reliable tech as soon as possible. Space planes are not the answer to that.
That's good to hear.
There are a number or really crappy USB network adapters out there. I've had very good luck with both D-Link and Belkin adapters with Tivo, but mileage varies. If you continue to have intermittent problems, and consider replacing the network adapter you might want to search the tivo community forum for recommendations.
Currently Tivo can only use USB 1.1 speeds to access the network. Under the upcoming release of the software, some network interfaces will be supported via USB 2.0 drivers enabling much faster network performance for both wired and wireless connections. If you decide to replace the network interface, it makes sense to choose one which has a supported USB2.0 driver.
Do some google searches or search the tivo community forum for info on this.
Sorry for jumping to conclusions.
For the past 4 weeks or so Tivo has been rolling out the
next major release of the OS. I'd bet they are deploying
several hundred to a thousand per night. I live on the
east coast, and have had no connection issues on any of my
Tivos. I know this because I check them once every evening to
see whether I've gotten the upgrade yet. (I got on the expedited
upgrade list weeks ago.)
Just out of curiosity, are you failing to connect at all (not getting
the clock set)? Or, are you failing far later.
Manually, connecting and watching the progress (which takes a
matter of minutes on a fast link) should narrow it down.
It is possible that your Tivos are trying to connect during peak
night time periods when OS downloads are happening.
Perhaps, you are timing out during download of the new OS yourself. And this is causing the failure.
Well the basic listing information already contains the information about whether it is new or a rerun.
Also, most networks submit additional listing information which is available locally on the tivo by hitting the "info" button from the episode screen. This information includes full credits for actors, director, etc., the original air date (when it was first released), episode number (e.g. 306 - season 3 episode 6).
So, the imdb hooks would only work for shows for which the network provides a full field set when they report to the listing integrator. All that information on an episode can already be viewed on the Tivo without making a network access.
I like the idea of keeping a persistent log of what episodes you have seen. However, the Tivo has very little memory, and disk access is precious since it already needs to do its index housekeeping, inter-Tivo networking etc., while recording one show in real-time (2 on a directivo) and playing back another.
In short, this doesn't sound worth any additional effort.
Of course it won't fix your negotiation problems because its a problem with your network, not theirs.
If you are connecting via a telephone line, you probably should look at your telephone wiring, and other devices connected to it. Perhaps you've got a device that changes the amount of power on the telephone line when your tivo attempts to make a call, or you try to use the phone often when when the tivo is thinking of calling. In that case it politely drops its attempt and waits another day.
If you are on a wired or wireless ethernet, check signal strength, and cabling.
Bottom line Tivo makes connection via TCP/IP. It used ppp over a POTS line, or vanilla IP over ethernet. None of my 3 Tivos have ever had a (failed negotiation) during the past 3-4 years. (2 via wired ethernet or phone line, 1 via phone line).
The problem is yours not theirs.
Display postscript was an official language distribution from adobe. In the late 80s early 90s it was developed as a serious contender to the X10/X11 display model. Many people confuse Display Postscript (hereafter called DPS) with other postscript related implementations.
NeWS (the Network Extensible Windowing System) was an independent implementation of postscript. It used a complete different set of objects to model display objects and handle events. It was similar in general flavor and purpose to DPS, but its major shortcomings were that it did not accept postcript type 1 fonts, and it was incompatible in a number of minor ways that meant that much output destined for HP printers (which used real postscript) did not render properly under NeWS.
Some people on the GNUStep team had been developing a display Ghostscript engine. Note that Ghostscript and postscript are independently developed engines. Thus when adobe dropped support for DPS it had no effect on that project.
I have not looked at GNUStep in several years, so am not intimately familiar with the details, but searching google today seems to indicate that that a native Display Ghostscript (DGS) system is no longer under development. Also, I note that an attempt to implement DPS as an extension to XFree86 also died about 4 years ago. So, my guess (and it is just a guess) is that DPS as a windowing system is a dead language.
I believe that GNUStep developers, instead, split the GUI layer into back end and front end parts. The actual GNUStep libraries that accept postscript fragments in display calls would then call either vanilla ghostscript to create a bitmap which would then be rendered using X11, or perhaps rendered via some other X11 rendering library that understands a subset of the postscript language. In any case, the interpretation of postscript fragments would be passed to an X11 based back end, and the windows, mouse events etc. would also be managed by X11. In real DPS these events were accepted by a small C base core, and the passed to objects running in the DPS interpreter. This is a significantly different model than GNUSTep appears to be using.
So I don't consider GNUStep dead, but do consider DPS dead.
DPS was an interpreter which managed display contexts for a system. It was a set of OO extensions to postscript. Basically one of the underlying types in postscript was a dictionary, an associative array like storage structure. Each window, menu, click-region, etc, was a an object whose members (and methods) were stored by name in dictionaries.
An interesting offshoot of this was that the real semantic guts of both news and dps was a postcript file. Adventurous users (or crazy, your call) could tweak certain aspects of appearance or behavior system wide. I briefly experimented with sloppy focus by tweaking the dps source code back in NeXTStep 1.x days.
Anyway, in the early Rhapsody days, Adobe set such high license fees for continuing to allow DPS use by NeXT/Apple, that Apple chose to stop using it. Since PDF supports a subset of PostScript, they decided to go that route instead. Most people I spoke to, agreed that it looked like the license fees were good evidence that Adobe wanted to drop DPS entirely and that their choice of pricing forced Apple's hand.
In the end, I feel that Apple made the right choice. It automatically meant that remote display protocols for Macos X would take a hit. However, it meant that local display performance would dramatically increase. Since that affects far more people, they made the most sensible choice.
Sorry that I was not able go give a very coherent answer here. This is ancient history. I hope you found it useful anyway.
if I find that a Linux, NetBSD or FreeBSD machine takes some 5 minutes to mount an NFS share on an OS X machine (with portmap running on all nodes) then I think that is reasonably good evidence that there's something wrong with the OS X implementation.
You are mistaken. Those symptoms are evidence that you do not have dns set up properly. A long delay followed by a successful mount suggests that one or both of the systems is timing out on name service queries. Those symtoms are consistent with missing 'A' records, missing 'PTR' records or both.
As for configuration, on any of my BSD or Linux boxes, all I need is a single line in my
You are correct that it requires more than adding a line to
1. Add a line to
2. Send a hup signal to mountd (killall -1 mountd) Or reboot.
How is that harder than BSD or linux? It is identical to BSDs. I admit that I'm guessing about the need to inform mountd to reload configurations on linux since I have not used it in 5 years.
To mount a remote volume manually you can use "connect to server" in the finder, or use mount from the command line. (This seems identical or easier than Linux depending on your approach).
To make volumes mount and unmount automatically, add a line to
The automount daemon adds a dynamic mount point for every fstab entry containing the 'net' option (this is equivalent to the 'mounts' domain in netinfo).
After restarting the automount daemon, or rebooting, when you refer to
Having administered dozens of Unices both commercial and free, I find that the various ways to get Macos X to work as an NFS client or server is either consistent with other unices, or nicer. Your sweeping claims that Macos X is broken merely reveal your ignorance of basic unix administration.
Don't get me wrong, client side NFS could be improved on Macos X. It handles manual mounts and automount(8) mounts flawlessly out of the box. My only complaint is that the port of amd (which comes bundled with the os for use by experts) is a bit sketchy when using complex map rules. I would prefer to use amd but ended up reverting to automount(8) about a year ago. I believe that Apple will eventually migrate from automount(8) to amd, but it is not ready for wide use yet.
Remote display made sense for display postscript in ways that no longer apply.
1. Instead of shipping bits around it would ship fragments of postcript code that when executed would produce the bits.
2. When asked to ship raw bits it was pretty slow.
3. For general purpose graphics the model was highly limiting because it basically drew into a dumb frame buffer which was blitted to the graphics card. Because of this it was never designed to use hardware acceleration.
4. Security was poor.
5. Adobe killed display postscript. Apple had to redesign a new display model from scratch. They chose pdf swince it incorporates a subset of postscript, though not the elements critical to making the old model work sell remotely.
The core graphics model in OSX now makes heavy use of hardware acceleration. Their is a fundamental tradeoff involved. You can have it fast, or you can have it remote. It made more sense to optimize for speed.
You can use and number of VNC clients and servers to run it remotely or use Apple's remote administration tool. These are relatively slow. Had they made remote windowing a priority it would have dramatically reduced their efficiency and speed for basic rendering.
The author had a good grasp of the high level architecture, but beyond that was clueless. His interpretation of the design is way off the mark.
He seemed astonished by the 1024 bit wide data paths. The Power family is design with cache fill lines of 128 bytes. So, for instance the G5 L2 cache already does fetches 128 bytes into cache for each main memory read.
Similarly all the talk about doing with cache and VM is bullshit. Instead of having each vector unit interfere with a shared cache as is done today, they've simply added smaller per ALU caches to the design, and complemented it with a device that is a souped up cache controller/MMU unit (the DMAC). The dmac apparently will be able to address both memory, and other hardware by having a virtual address layer, to enable reference to remote cell units as well as local physical hardware. The 64 MB of high speed rambus memory, may be all that is required for a PS3, but in a workstation implementation that memory is L3 cache.
Altivec currently has 32 vector registers. Each ALU as 128. It it highly likely that the core opcode architecture will remain similar. The most likely addition will be to add a few flow control instructions to the existing mix.
Altivec is already powerful but the biggest limiting factor is latency. Altivec can peform 1 instruction per clock on the G5, However the pipeline is 8 levels deep thus the overhead involved in fetching data, loading registers, performing a calculation among 1-3 registers, and getting a result is prohibitively expensive. However, if you can arrange to submit 8 calculations (or more) in rapid sequence, you can keep Altivac and the CPU busy and reap great benefits.
The beauty of Cell will be in proving the ALUs with a bit more autonomy (thought not much more, they are still basically vector units), and enabling the main CPU to keep doing useful work while a number of ALUs are cranking away. Other novel design features provide for communication and synchronization with other units via remote addressing and timing (that's what those realtime clock signals are all about).
This will be very fast, and very cheap. However, all the hand waving, and theorizing this guy does about both hardware and software reads like patent bullshit.