but while it's true that the US is (37 times) bigger than the UK, so is the population, and therefore the opportunity for investment
I think the logistics just don't scale so easily. I think many people outside of the US think of it as just another country, but it is really almost like 50 different countries with different cultures, demographics, geographies, laws etc. Even more when you consider the differences between say Northern/Central/Southern California.
For instance I live in Central California which is full of mountains and gulches and such. Even in Silicon Valley, which you would think would be an obvious focus area, there are stretches of open grazing ranges and rolling hills in between the clusters of activity. So just driving 20 minutes from San Jose to Palo Alto I can't guarantee I'll get a connection. I generally don't have coverage problems in any 'downtown' areas, just in areas where one could see there might be difficulties.
As far as coverage in the rural parts of the country, I can't imagine how companies could justify cell towers in places where the population density is low. Just as a reference, compare the overall population density of the UK versus US:
UK: 244.7 people per sq. km
US: 29.7 people per sq. km
and then you compare the individual states:
New Jersey: 438.00 people per sq. km
California: 83.85 people per sq. km
Wyoming: 1.96 people per sq. km.
So it makes sense that the providers will focus on local solutions and there will be lots of dead spots in between. Quite the challenge, I'd say.
Not really trying to apologize for the poor coverage in US, but you might want to consider that the size of the UK is about the size of Michigan. Then there's 49 other states to take into account.
Area of UK: 94,525 sq. mi.
Area of US: 3,537,441 sq. mi.
That makes the US about 37 times the size of the UK - a slightly larger technical/economical challenge.
Sorry if you can't handle MY OPINIONS. If you disagree with them, then say so, preferably with new information that disputes my conclusions, instead of simply cliche name calling.
EEE and FUD as a strategic policy is a FACT in many companies, not just M$. Whether Mr. Hilf himself is a bad guy or not, of that I have no direct information. But I KNOW for a FACT that the company he works for would never let him speak out on a place like Slashdot without it supporting their corporate strategy.
I've read the Halloween documents. I've seen The Corporation. I've read Brave New World. I've worked on multi-million dollar projects partnered with players in the big leagues. I've been in meeting after meeting where war analogies were thrown around like they were talking about combatting the devil himself. I've seen good people's careers and entire companies crushed in the name of Corporate Stability when in fact it was all about bucks and power for a few that came and left, at the expense of the many who remained to futilely try to clean up the mess and continue to make their house payments.
I was young and naive at one time. Call me arrogant if you want, but I've been there and played that game, so I just call it direct experience from hard learned lessons. If you don't want to believe that's the way the game is played, then you just keep thinking that way. That's exactly what makes it all work - lot's of spectators thinking it is really just a game and very few players who know it isn't.
I didn't create the reasons people blow themselves up in crowds. But I can understand just how they can be driven to that point. If you want to know why they do it, then just open your eyes. The world is full of bad guys in suits and claiming to be your friend.
And what I was saying is that what you call 'valid responses' is absolutely 100% just PR stuff in disguise, just as the parent poster was claiming. There is NO WAY that this guy would be allowed to say ANYTHING so publicly without it being calculated into the ultimate strategy of the company. This is not some low-level engineer making some offhand remarks after a couple of drinks at a bar. These statements are absolutely ON THE RECORD speaking directly to their most feared ENEMY. It's a very clever, well honed TACTIC - I don't think you really get that fully.
I bet you believe that the Bush team is really at war in the middle-east to promote democracy around the world also...
Umm, what about the stuff where they discovered a bug in GAIM talking to MSN over HTTP ?
You apparently don't know much about the game of "hard ball".
It's like organized crime, where they donate a few bucks to the local churches and kids programs to show a soft public side, meanwhile they are selling drugs and strong arming the local businesses in the back rooms. The public show allows people to believe they're really 'good at heart' and the rest is just 'part of the business'.
It's also very possible that the GAIM people knew that M$ was inspecting thier code and if M$ didn't report the errors the GAIM people could make a public statement that M$ was aware of this and didn't say anything, and turn it into a public negative. I bet there are plenty of flaws in other vendor's code that they never reported. But they keep a few instances around to name-drop so that they can say "look at how we're being good guys".
This is exactly what the first E in the EEE is all about - "Embrace". Make it look like you are working along side everybody else. But don't forget about the "Extend" and "Extinguish" parts. It's tactic versus strategy. Ultimately it is M$'s goal to extinguish their competition (as is the case with most businesses...).
Don't be fooled by the smiles and hand-shaking of the day. Look at the long term results and implications.
AFAIK, a tile did not fall off of Challenger - a piece of foam fell off during takeoff and hit some tiles on the wing and damaged them. leaving a hole in the wing.
"Don't measure everything against what a company like M$ did" Why Not?
I guess you missed my point. One reason is that what M$ did to establish their monopoly was found to be largely illegal. Are you saying Apple should have also broken the law? Maybe from M$'s perspective it was all just a financial tradeoff - make $50B and pay $2B in fines and legal fees. Sorry, that doesn't fit within my ethical boundaries - especially if it was an intentional business strategy decision, which I personally believe is the case.
The rest of your points are mostly just 'coulda, shoulda, woulda'. You weren't there in the meetings. You don't know what really went on and who was squeezing whose balls. There are stories about how Apple caught M$ with stealing some QuickTime code or something, about M$ strong arming vendors to not support Apple technology - all that kinda stuff that happened with Netscape and Sun and other stuff like that was going on against Apple also. That's hard ball stuff, and again, bottom line, Apple 'somehow' got what they needed from M$. We'll probably never know what really happened.
I say, yes, cut them some slack, as their influence on the world is undeniable. Yes, they made some mistakes, and they learned from them like a good business should, and meanwhile they figured out a way to change the world and survive in a market where others couldn't. That's due to some pretty good businessman's work along the way, if you ask me, as well as many other intangibles and unknowables.
They are exceptionnal engineers and very lousy businessman
And exactly how many companies that were making desktop computers in the '70s are still around today, have tens of millions of paying customers, and billions in the bank?
Get a clue. Don't measure everything against what a company like M$ did, much of which has since been determined to be illegal. Apple's business sense has been just fine. The company has weathered many storms precisely because they had financial buffers that the businessmen put in place as the technology landscape unfolded. No one knew exactly how it was all going to turn out, and most crashed and burned along the way. You should wish that you were so 'lousy' at succeeding in any business, let alone the cut throat computer business.
But I know my Unix and Linux based hosts and applications won't be a problem.
Famous last words from someone who seems to have a serious backup of testosterone. Unless you've written all the code for all the tools your clients rely on, I can't see how you can possibly know for sure what is going to happen.
The *good* admins I know never say never. They say "let's do this just in case. It's not worth taking any chances in the middle of a project".
I believe time servers report some sort of untranslated time, like Universal or Greenwich Mean. Your local machine then adjusts the displayed time locally, so I think it will still be an issue for you.
Hey, I think that's kinda funny. Just because you don't agree with someone doesn't make them a troll. Maybe -.5 Flamebait, but not troll.
Personally I think C++ was a poor choice to standardize on. It was just in the right place at the right time with heavier promotion than the competition. I yell at it all the time and I blame it for my growing bald spot, even as I collect paychecks for battling the beast. I much prefer ObjC - actually ObjC++ because I like *some* of the C++ extensions beyond C, like to declare variables right at the places I need them, and in for() statements.
Revision controlled files are kept in a database of some kind, typically on a remote server. You never want to see the database files themselves, you want to see/get some revision that has been pulled out of the database (repository) or you want to submit a previously checked out (and possibly edited) version of the file back into the database. So a raw file transfer or server protocol won't do you any good - you need the database manager to do the get/diff/merge/put for you.
Whether those revision management tasks are done from within a standalone GUI app, the command line, or a web browser are irrelevant to the task needs. There is no reason a web browser interface couldn't be made to do the work. The SVN book is just saying that simply using mod_dav_svn isn't enough. It 's not just a raw file transfer in either direction - it would have to be some server side app or client side plugin to the browser that handled all the required database management issues. Maybe something like that will be developed at some point, but apparently it's not a priority yet.
A well written task specific tool should always be easier to use than trying to make a browser do everything. If that weren't the case, all applications would go away and the only one you'd have is a browser (and a whole lot of plugins.) (Uh, didn't M$ try to do that and got slapped?!)
I personally don't see the need for everything to be done through a browser interface. I guess for people that aren't very technically savvy that seems the most comfortable, until they realize that what they need to do is a bit more complicated than just clicking on links. A tool with appropriate window layouts, tables, buttons, menus and such that visually and logically model what you are trying to do seems like a better approach. Not everything fits into a viewing window with links and next/prev buttons model, which is what a web brower is mostly about.
I didn't mean to dis you specifically - I just noticed that so many posts on this thread are convinced that FTP is the only way to go for accessing remote files. FTP is fine if you just want to get/put something, but it isn't the same thing at all as a networked file system.
The OP didn't specify exactly what use cases they wanted to accomplish with their accessibility to remote files. If it is just put/get, then FTP is fine. But WebDAV can do put/get as well as secure and faster inline viewing/editing, so it seems that it is a more capable general purpose service. Unless they want to explicitly not support inline access for some reason.
I don't understand your svn issues. What exactly are you looking for? Revision control and file serving are pretty much orthogonal tasks.
Nowhere in his post did he say that you couldn't save using FTP. He mentioned no need for 'uploading and downloading', which, granted, is a bit technically misleading. Of course data needs to be up/downloaded with any kind of remote server. My interpretation of what he meant by those terms was the 'full file download/full file upload' scenario as opposed to the potential for partial range loading and file locking available using WebDAV.
Range loading could be a be huge time savings if you wanted to view a very large remote file. Most sophisticated data viewers/editors will only page in the data needed on an as needed basis. I'm pretty sure even vi does this - so it opens very quickly on the first page of even very large files.
The file locking ability of WebDAV is especially important for any kind of collaborative development, like if a team of people are maintaining a web site with all the files on a remote server. It 'used to be' very easy for all kinds of collisions. This is exactly what WebDAV was designed to solve.
I don't get why people just don't get the difference between a file transfer model versus a networked file system. People on this site are supposed to be somewhat technically savvy. Yet so many seem to be stuck in some world where 'I've been using FTP for years and no new fangled technology can possibly be better'. Wake up! Problems are being solved all the time - you now have a choice that can make your work easier, faster and safer.
Maybe 'uploading and downloading" is a bit vague, and maybe you were just trying do some semantics policing, but for those don't understand it all, WebDAV works very differently than FTP as far as opening, editing and saving files. It's like saying what is the difference between FTP and SMB/AFP/NFS.
You can kinda edit files on an FTP server through some hackery, but it has a slew of problems. Essentially the entire file is downloaded to a temp file, then the temp file is edited, then the entire thing is uploaded on save.
WebDAV is a networked filesystem like SMB/AFP/NFS. The editing app doesn't have to have any special support, as the file is opened/edited/saved just as if it is a local file using standard file open/read/seek/write APIs. Only the range of data that the app needs to view/edit have to be down/uploaded as the app does reads/writes (just like any networked file system.) The remote WebDAV server also supports true file locking so that someone else can't open/edit the file while it is in use (as well as other meta data like MIME type etc.).
With FTP someone could download a file, start editing, and meanwhile someone else could download/edit/upload, then the first user uploads changes and overwrites the first edits.
So yeah, in both FTP and remote filesystems data is 'uploaded and downloaded'. But the difference in protocols makes a big difference in how it all works to the end user.
the issue of drivers [...] These issues apply equally to USB and FireWire.
It's not an 'equal' issue. You must have missed my point about a USB host having to 'broker' all transactions. If you had a USB Host video camera hooked up to an audio mixer console, an audio IO box, an effects box and a hard drive, the camera would have to have drivers for all of those other devices and broker all transactions between them, since it is the 'monkey in the middle'. If it was an all FireWire system the IO box could stream data directly to the effects box then the audio data could go directly to the hard drive, and the mixer console could directly control both the effects box and IO box, all while the video stream was also going to the hard drive. All of this would typically have to be synced to some master clock, which would likely be the camera, since it is probably putting out the time codes. The camera wouldn't have to know anything about the audio protocols floating around the bus.
But what the previous poster was implying was that USB required a âhost computerâ(TM) with COMPUTER being the keyword. USB does NOT have to be hosted or controlled by a COMPUTER. The USB controller/host can be in a consumer device and a 'host COMPUTER' is NOT required.
Well maybe it's just a semantic argument then, but your use of the terms 'host computer' are pretty lax. Many would even consider your usage just plain wrong.
A 'host computer' is one that hosts. If it has a USB Host controller chip in it, and it hosts peripherals, it is a host computer. A USB peripheral has a bus controller chip in it, and therefore it is not a host. The USB-IF would call any system with a USB host chip in it a 'host computer'. It's not being pedantic, it's just using the correct terminology (Engineering academics don't stop at Networking 101).
What you probably mean is 'general purpose' computer, presuming you mean something like a Mac/PC.
I have developed computer based consumer and pro products for many years that have pre-emptive real-time kernels, memory management, bulk storage subsystems (IDE, SCSI), graphics terminals, keyboards, mice etc. (along with a bunch of custom ASICs). They are definitely 'host computers', though they are 'dedicated purpose', not 'general purpose'.
One can develop a device that is a USB Host or one can build a FireWire device. The USB host device will likely be cheaper than the FireWire device. And you can plug in a lot of cheap peripheral things into it. But it has limits. Issues we had in our systems were that we wanted to connect two or more of our system together, support connecting mice and external hard drives, as well as having it connected to a 'general purpose' computer like a Mac/PC. Trying to do that all with USB is just a nightmare. So our systems actually wound up with both USB Host and FireWire. The USB host was used to connect things like mice, and backup drives. The FireWire is used to interconnect machines and also to the Mac/PC.
Sorry if I assumed too much ignorance on your part. You seem to understand the concepts but used rather vague terminology. I am probably more inclined than you to use the terminology of the developers of the technology and most working engineers, having been developing computer systems for over 20 years. I felt your post could easily be misinterpreted by others. I have had plenty of customers (and Marketing people) ask me what the difference is between USB and FireWire. They tend to focus on the comparable speed, and they look at the cost differential and ask 'why?'. USB and FireWire have different goals and purposes and though it can get technical, it needs to be understood why one would choose to develop a USB versus FireWire host device. A FireWire system will ultimately be far more powerful than a USB Host only system. Having both FireWire and USB Host gives you the ultimate system - the best of both worlds for only a few bucks more.
No, it's not *exactly* like FireWire. Actually it's not the same at all.
FireWire is a true peer-to-peer model and can work in a ring or star mode. USB uses a Host-Periphieral model where all data must go through the host and only operates in a tree mode with the host at the root. If it is both host and peripheral, it is a leaf on the peripheral end and the root of another tree on the host end.
In FireWire if you have three devices device A can send and receive data directly to/from device C. If it's in a star mode you need a hub, but that doesn't put any load on any of the other devices and is essentially just routing. In ring mode device A sends the data to device B but it just passes it through at the hardware level to device C. You can combine stars and rings, but that is just phyiscal and not logical, as the data is essentially still just passed from one device to the other with no software processing required by any of the intervening devices.
In USB you have a Host and a Peripheral. First off, the host must essentially 'poll' each peripheral to see if it has anything to say. A peripheral cannot initiate a transaction. The polling happens each frame, which is 1 msec in USB 1.x. Secondly, if you want to send from device A to device C you really have to tell the host that you want to send the data to C, then it asks C if it is OK, then the host essentially brokers all the transactions. All the data has to go into the host, get buffered and prioritized and repacketized and peeked and poked and then is turned around to device C, mostly all in software running on the host processor.
FireWire uses a collision avoidance scheme on the virtually shared wire similiar to the way ethernet works. There is no host required to poll peripherals or broker and process all the transactions.
Devices that have both a host and peripheral controller means it has to have 2 connectors since they are different physically. (There is that USB2Go thing, but that's really just a repackaging of the hardware, while all the same host-peripheral and sofware issues remain.) While it is a peripheral it is at the mercy of whatever the host is allowing on that side of the fence. You don't really get a star, you get a messy tree with a slew of idiocsyncracies, and delivery times that become very unpredictable.
If you want to be a host, then you have to essentially replicate what the major OS vendors have done as far as driver support and such. Host controller software is infintely more complicated to implement than peripheral software. It has to have drivers for all the possible peripherals that may be connected to it, and possibly support loading of drivers (at least for updates and such, if not to work with mfg. exclusive-class peripherals). It has to be able to a whole bunch of stuff, hard stuff like scheduling for all the peripherals. If this custom host is also to be a peripheral of say a computer or other host, it has to deal with bridging between the other host and the peripherals connected to it. It has to intervene on every transaction. If you want any kind of throughput you have to have a pretty heavy duty microcontroller to do all that work.
Then there is the issue of drivers. The host has to have native drivers for all the peripherals it is to support. When the peripheral is plugged in it has to negotiate with a driver that knows how to talk to it. The host can't ID a device that it doesn't have a driver for. So if you had a camera, a printer and some weird host in between, that host would have to support both devices with drivers just to pass data between them. Do you think the scanner and camera manufacturers are going to provide drivers for every propietary host OS? It's hard enough to get drivers for Mac/Win/Linux/Unix OSs. In FireWire only the two devices that are communicating need to support a common protocol, since any other device in the ring or star would just be passing around the raw data and doesn't have to support each device.
Not every company is a cluster of drones that merely 'do what they are told to do with tools they are given'. Some places actually allow their employees to think for themselves and make decisions. Some places encourage diversity and experimentation.
Security concerns, though obviously necessary to some degree, are commonly abused as an excuse for needing to control people. But usually the need to control others has little to do with security or productivity, but instead is all about ego or other self-interests of managers.
The role of an administrator is to deliver and maintain whatever services are appropriate in a given environment as defined by the policy makers.
It may be that in your work environment, the policy, for some unknown reason, is to limit people's creativity and to eliminate their individual power. So the admin's job is then to deliver and maintain straight jackets and blinders for all employees.
I feel sorry for the people that must work in such a stifling environment. I imagine that not having Rendezvous enabled devices is probably the least of their worries.
This is just outright bullshit. Why do people make up shit like this?
Apple has already developed and released the library code and even example client application code specifically targeted at Posix, Win32 and VxWorks systems as well as OS 9 and OS X. It's on the Public Source website. And all the portable stuff is all in C. The only objective-C stuff are the parts that are specifically targeted at OS X development.
And what exactly is 'PPC only code in objective-c'. Do you even know what code is?
I've only read a bit about it, but as far as I understand it, Rendezvous systems only broadcast when they first come on line. They broadcast - 'Here I am and here are my services'. At that point all the other machines on the net cache that info. Then they broadcast a 'who else is out there' message' so that they can sync up with other machines that booted previously. If any new service comes on line after bootup, only the info for that new service is broadcast, and only once. So, once a network is set up, there are no 'continuous' broadcasts to clog the network. I believe a system can broadcast a message to tell the net to resync at any time, but that is not normally required and shouldn't happen very often.
One of the reasons why Apple systems became so popular in the 80's was because of this type of technology that they developed (i.e. AppleTalk Name Binding Protocol). A small publishing business could take a few Macs and a LaserWriter and plug them together using simple cabling and magically the printer just appeared in everyone's Chooser. No print servers required, no DNS, no DHCP. It all 'just worked' the way people needed and wanted it to work.
Since then, networks have gotten more pervasive, and the kinds of peripherals available are much greater and more sophisticated than just printers. So Apple learned from their mistakes (e.g. the chattiness of AT), updated for new types of peripherals and networking requirements and essentially developed (with other peer companies) a next generation of AppleTalk NBP, and they call it Rendezvous/ZeroConf.
Microsoft has simililar technology already in SMB. But most would agree that it is very hard to set up without significant technical expertise and of course it is proprietary, among other well documented limitations.
What is so annoying in threads like this is that so many people just make shit up with a predisposed biased perspective because Apple had something to do with it, and assume Apple can't do anything right. And then so many other people just run with the crap. They assume that some idiot made up some stupid protocol and that there was no thought process and no peer review. They never read the docs and talk about real information. They can't imagine that some smart people may have actually come up with a cool idea, thought about the potential issues and tradeoffs, and solved them as best as anyone could. Luckily there are a few people that try to comat the crap, but most just ignore the real information and continue on spouting the crap, because they really just want to bash.
Just wait a year or so. Rendezvous will be ubiquitous. And people will be benefitting from it and wonder how they ever lived without it. Apple will have lead the way, yet again. And Windows and Linux users will benefit from it just as much as Apple users.
Slashdot Mirror
I think the logistics just don't scale so easily. I think many people outside of the US think of it as just another country, but it is really almost like 50 different countries with different cultures, demographics, geographies, laws etc. Even more when you consider the differences between say Northern/Central/Southern California.
For instance I live in Central California which is full of mountains and gulches and such. Even in Silicon Valley, which you would think would be an obvious focus area, there are stretches of open grazing ranges and rolling hills in between the clusters of activity. So just driving 20 minutes from San Jose to Palo Alto I can't guarantee I'll get a connection. I generally don't have coverage problems in any 'downtown' areas, just in areas where one could see there might be difficulties.
As far as coverage in the rural parts of the country, I can't imagine how companies could justify cell towers in places where the population density is low. Just as a reference, compare the overall population density of the UK versus US:
UK: 244.7 people per sq. km
US: 29.7 people per sq. km
and then you compare the individual states:
New Jersey: 438.00 people per sq. km
California: 83.85 people per sq. km
Wyoming: 1.96 people per sq. km.
So it makes sense that the providers will focus on local solutions and there will be lots of dead spots in between. Quite the challenge, I'd say.
Area of UK: 94,525 sq. mi.
Area of US: 3,537,441 sq. mi.
That makes the US about 37 times the size of the UK - a slightly larger technical/economical challenge.
Uh, compile OS X, *BSD and practically every application that runs on them?
Sorry if you can't handle MY OPINIONS. If you disagree with them, then say so, preferably with new information that disputes my conclusions, instead of simply cliche name calling.
EEE and FUD as a strategic policy is a FACT in many companies, not just M$. Whether Mr. Hilf himself is a bad guy or not, of that I have no direct information. But I KNOW for a FACT that the company he works for would never let him speak out on a place like Slashdot without it supporting their corporate strategy.
I've read the Halloween documents. I've seen The Corporation. I've read Brave New World. I've worked on multi-million dollar projects partnered with players in the big leagues. I've been in meeting after meeting where war analogies were thrown around like they were talking about combatting the devil himself. I've seen good people's careers and entire companies crushed in the name of Corporate Stability when in fact it was all about bucks and power for a few that came and left, at the expense of the many who remained to futilely try to clean up the mess and continue to make their house payments.
I was young and naive at one time. Call me arrogant if you want, but I've been there and played that game, so I just call it direct experience from hard learned lessons. If you don't want to believe that's the way the game is played, then you just keep thinking that way. That's exactly what makes it all work - lot's of spectators thinking it is really just a game and very few players who know it isn't.
I didn't create the reasons people blow themselves up in crowds. But I can understand just how they can be driven to that point. If you want to know why they do it, then just open your eyes. The world is full of bad guys in suits and claiming to be your friend.
And what I was saying is that what you call 'valid responses' is absolutely 100% just PR stuff in disguise, just as the parent poster was claiming. There is NO WAY that this guy would be allowed to say ANYTHING so publicly without it being calculated into the ultimate strategy of the company. This is not some low-level engineer making some offhand remarks after a couple of drinks at a bar. These statements are absolutely ON THE RECORD speaking directly to their most feared ENEMY. It's a very clever, well honed TACTIC - I don't think you really get that fully.
I bet you believe that the Bush team is really at war in the middle-east to promote democracy around the world also...
Umm, what about the stuff where they discovered a bug in GAIM talking to MSN over HTTP ?
You apparently don't know much about the game of "hard ball".
It's like organized crime, where they donate a few bucks to the local churches and kids programs to show a soft public side, meanwhile they are selling drugs and strong arming the local businesses in the back rooms. The public show allows people to believe they're really 'good at heart' and the rest is just 'part of the business'.
It's also very possible that the GAIM people knew that M$ was inspecting thier code and if M$ didn't report the errors the GAIM people could make a public statement that M$ was aware of this and didn't say anything, and turn it into a public negative. I bet there are plenty of flaws in other vendor's code that they never reported. But they keep a few instances around to name-drop so that they can say "look at how we're being good guys".
This is exactly what the first E in the EEE is all about - "Embrace". Make it look like you are working along side everybody else. But don't forget about the "Extend" and "Extinguish" parts. It's tactic versus strategy. Ultimately it is M$'s goal to extinguish their competition (as is the case with most businesses...).
Don't be fooled by the smiles and hand-shaking of the day. Look at the long term results and implications.
AFAIK, a tile did not fall off of Challenger - a piece of foam fell off during takeoff and hit some tiles on the wing and damaged them. leaving a hole in the wing.
"Don't measure everything against what a company like M$ did"
Why Not?
I guess you missed my point. One reason is that what M$ did to establish their monopoly was found to be largely illegal. Are you saying Apple should have also broken the law? Maybe from M$'s perspective it was all just a financial tradeoff - make $50B and pay $2B in fines and legal fees. Sorry, that doesn't fit within my ethical boundaries - especially if it was an intentional business strategy decision, which I personally believe is the case.
The rest of your points are mostly just 'coulda, shoulda, woulda'. You weren't there in the meetings. You don't know what really went on and who was squeezing whose balls. There are stories about how Apple caught M$ with stealing some QuickTime code or something, about M$ strong arming vendors to not support Apple technology - all that kinda stuff that happened with Netscape and Sun and other stuff like that was going on against Apple also. That's hard ball stuff, and again, bottom line, Apple 'somehow' got what they needed from M$. We'll probably never know what really happened.
I say, yes, cut them some slack, as their influence on the world is undeniable. Yes, they made some mistakes, and they learned from them like a good business should, and meanwhile they figured out a way to change the world and survive in a market where others couldn't. That's due to some pretty good businessman's work along the way, if you ask me, as well as many other intangibles and unknowables.
They are exceptionnal engineers and very lousy businessman
And exactly how many companies that were making desktop computers in the '70s are still around today, have tens of millions of paying customers, and billions in the bank?
Get a clue. Don't measure everything against what a company like M$ did, much of which has since been determined to be illegal. Apple's business sense has been just fine. The company has weathered many storms precisely because they had financial buffers that the businessmen put in place as the technology landscape unfolded. No one knew exactly how it was all going to turn out, and most crashed and burned along the way. You should wish that you were so 'lousy' at succeeding in any business, let alone the cut throat computer business.
But I know my Unix and Linux based hosts and applications won't be a problem.
Famous last words from someone who seems to have a serious backup of testosterone. Unless you've written all the code for all the tools your clients rely on, I can't see how you can possibly know for sure what is going to happen.
The *good* admins I know never say never. They say "let's do this just in case. It's not worth taking any chances in the middle of a project".
I.e. "Sh*t happens".
I believe time servers report some sort of untranslated time, like Universal or Greenwich Mean. Your local machine then adjusts the displayed time locally, so I think it will still be an issue for you.
sorry, I meant that for the parent post, not the 'boo hoo' post.
Though your post sounds like flamebait to me, I will begrudgingly respond...
I imagine someone actually had to write some software to run the thing. That would make the development environment/desktop quite relevant.
Hey, I think that's kinda funny. Just because you don't agree with someone doesn't make them a troll. Maybe -.5 Flamebait, but not troll.
Personally I think C++ was a poor choice to standardize on. It was just in the right place at the right time with heavier promotion than the competition. I yell at it all the time and I blame it for my growing bald spot, even as I collect paychecks for battling the beast. I much prefer ObjC - actually ObjC++ because I like *some* of the C++ extensions beyond C, like to declare variables right at the places I need them, and in for() statements.
Whether those revision management tasks are done from within a standalone GUI app, the command line, or a web browser are irrelevant to the task needs. There is no reason a web browser interface couldn't be made to do the work. The SVN book is just saying that simply using mod_dav_svn isn't enough. It 's not just a raw file transfer in either direction - it would have to be some server side app or client side plugin to the browser that handled all the required database management issues. Maybe something like that will be developed at some point, but apparently it's not a priority yet.
A well written task specific tool should always be easier to use than trying to make a browser do everything. If that weren't the case, all applications would go away and the only one you'd have is a browser (and a whole lot of plugins.) (Uh, didn't M$ try to do that and got slapped?!)
I personally don't see the need for everything to be done through a browser interface. I guess for people that aren't very technically savvy that seems the most comfortable, until they realize that what they need to do is a bit more complicated than just clicking on links. A tool with appropriate window layouts, tables, buttons, menus and such that visually and logically model what you are trying to do seems like a better approach. Not everything fits into a viewing window with links and next/prev buttons model, which is what a web brower is mostly about.
I didn't mean to dis you specifically - I just noticed that so many posts on this thread are convinced that FTP is the only way to go for accessing remote files. FTP is fine if you just want to get/put something, but it isn't the same thing at all as a networked file system.
The OP didn't specify exactly what use cases they wanted to accomplish with their accessibility to remote files. If it is just put/get, then FTP is fine. But WebDAV can do put/get as well as secure and faster inline viewing/editing, so it seems that it is a more capable general purpose service. Unless they want to explicitly not support inline access for some reason.
I don't understand your svn issues. What exactly are you looking for? Revision control and file serving are pretty much orthogonal tasks.
Nowhere in his post did he say that you couldn't save using FTP. He mentioned no need for 'uploading and downloading', which, granted, is a bit technically misleading. Of course data needs to be up/downloaded with any kind of remote server. My interpretation of what he meant by those terms was the 'full file download/full file upload' scenario as opposed to the potential for partial range loading and file locking available using WebDAV.
Range loading could be a be huge time savings if you wanted to view a very large remote file. Most sophisticated data viewers/editors will only page in the data needed on an as needed basis. I'm pretty sure even vi does this - so it opens very quickly on the first page of even very large files.
The file locking ability of WebDAV is especially important for any kind of collaborative development, like if a team of people are maintaining a web site with all the files on a remote server. It 'used to be' very easy for all kinds of collisions. This is exactly what WebDAV was designed to solve.
I don't get why people just don't get the difference between a file transfer model versus a networked file system. People on this site are supposed to be somewhat technically savvy. Yet so many seem to be stuck in some world where 'I've been using FTP for years and no new fangled technology can possibly be better'. Wake up! Problems are being solved all the time - you now have a choice that can make your work easier, faster and safer.
Maybe 'uploading and downloading" is a bit vague, and maybe you were just trying do some semantics policing, but for those don't understand it all, WebDAV works very differently than FTP as far as opening, editing and saving files. It's like saying what is the difference between FTP and SMB/AFP/NFS.
.
You can kinda edit files on an FTP server through some hackery, but it has a slew of problems. Essentially the entire file is downloaded to a temp file, then the temp file is edited, then the entire thing is uploaded on save.
WebDAV is a networked filesystem like SMB/AFP/NFS. The editing app doesn't have to have any special support, as the file is opened/edited/saved just as if it is a local file using standard file open/read/seek/write APIs. Only the range of data that the app needs to view/edit have to be down/uploaded as the app does reads/writes (just like any networked file system.) The remote WebDAV server also supports true file locking so that someone else can't open/edit the file while it is in use (as well as other meta data like MIME type etc.)
With FTP someone could download a file, start editing, and meanwhile someone else could download/edit/upload, then the first user uploads changes and overwrites the first edits.
So yeah, in both FTP and remote filesystems data is 'uploaded and downloaded'. But the difference in protocols makes a big difference in how it all works to the end user.
It's not an 'equal' issue. You must have missed my point about a USB host having to 'broker' all transactions. If you had a USB Host video camera hooked up to an audio mixer console, an audio IO box, an effects box and a hard drive, the camera would have to have drivers for all of those other devices and broker all transactions between them, since it is the 'monkey in the middle'. If it was an all FireWire system the IO box could stream data directly to the effects box then the audio data could go directly to the hard drive, and the mixer console could directly control both the effects box and IO box, all while the video stream was also going to the hard drive. All of this would typically have to be synced to some master clock, which would likely be the camera, since it is probably putting out the time codes. The camera wouldn't have to know anything about the audio protocols floating around the bus.
But what the previous poster was implying was that USB required a âhost computerâ(TM) with COMPUTER being the keyword. USB does NOT have to be hosted or controlled by a COMPUTER. The USB controller/host can be in a consumer device and a 'host COMPUTER' is NOT required.
Well maybe it's just a semantic argument then, but your use of the terms 'host computer' are pretty lax. Many would even consider your usage just plain wrong.
A 'host computer' is one that hosts. If it has a USB Host controller chip in it, and it hosts peripherals, it is a host computer. A USB peripheral has a bus controller chip in it, and therefore it is not a host. The USB-IF would call any system with a USB host chip in it a 'host computer'. It's not being pedantic, it's just using the correct terminology (Engineering academics don't stop at Networking 101).
What you probably mean is 'general purpose' computer, presuming you mean something like a Mac/PC.
I have developed computer based consumer and pro products for many years that have pre-emptive real-time kernels, memory management, bulk storage subsystems (IDE, SCSI), graphics terminals, keyboards, mice etc. (along with a bunch of custom ASICs). They are definitely 'host computers', though they are 'dedicated purpose', not 'general purpose'.
One can develop a device that is a USB Host or one can build a FireWire device. The USB host device will likely be cheaper than the FireWire device. And you can plug in a lot of cheap peripheral things into it. But it has limits. Issues we had in our systems were that we wanted to connect two or more of our system together, support connecting mice and external hard drives, as well as having it connected to a 'general purpose' computer like a Mac/PC. Trying to do that all with USB is just a nightmare. So our systems actually wound up with both USB Host and FireWire. The USB host was used to connect things like mice, and backup drives. The FireWire is used to interconnect machines and also to the Mac/PC.
Sorry if I assumed too much ignorance on your part. You seem to understand the concepts but used rather vague terminology. I am probably more inclined than you to use the terminology of the developers of the technology and most working engineers, having been developing computer systems for over 20 years. I felt your post could easily be misinterpreted by others. I have had plenty of customers (and Marketing people) ask me what the difference is between USB and FireWire. They tend to focus on the comparable speed, and they look at the cost differential and ask 'why?'. USB and FireWire have different goals and purposes and though it can get technical, it needs to be understood why one would choose to develop a USB versus FireWire host device. A FireWire system will ultimately be far more powerful than a USB Host only system. Having both FireWire and USB Host gives you the ultimate system - the best of both worlds for only a few bucks more.
No, it's not *exactly* like FireWire. Actually it's not the same at all.
FireWire is a true peer-to-peer model and can work in a ring or star mode. USB uses a Host-Periphieral model where all data must go through the host and only operates in a tree mode with the host at the root. If it is both host and peripheral, it is a leaf on the peripheral end and the root of another tree on the host end.
In FireWire if you have three devices device A can send and receive data directly to/from device C. If it's in a star mode you need a hub, but that doesn't put any load on any of the other devices and is essentially just routing. In ring mode device A sends the data to device B but it just passes it through at the hardware level to device C. You can combine stars and rings, but that is just phyiscal and not logical, as the data is essentially still just passed from one device to the other with no software processing required by any of the intervening devices.
In USB you have a Host and a Peripheral. First off, the host must essentially 'poll' each peripheral to see if it has anything to say. A peripheral cannot initiate a transaction. The polling happens each frame, which is 1 msec in USB 1.x. Secondly, if you want to send from device A to device C you really have to tell the host that you want to send the data to C, then it asks C if it is OK, then the host essentially brokers all the transactions. All the data has to go into the host, get buffered and prioritized and repacketized and peeked and poked and then is turned around to device C, mostly all in software running on the host processor.
FireWire uses a collision avoidance scheme on the virtually shared wire similiar to the way ethernet works. There is no host required to poll peripherals or broker and process all the transactions.
Devices that have both a host and peripheral controller means it has to have 2 connectors since they are different physically. (There is that USB2Go thing, but that's really just a repackaging of the hardware, while all the same host-peripheral and sofware issues remain.) While it is a peripheral it is at the mercy of whatever the host is allowing on that side of the fence. You don't really get a star, you get a messy tree with a slew of idiocsyncracies, and delivery times that become very unpredictable.
If you want to be a host, then you have to essentially replicate what the major OS vendors have done as far as driver support and such. Host controller software is infintely more complicated to implement than peripheral software. It has to have drivers for all the possible peripherals that may be connected to it, and possibly support loading of drivers (at least for updates and such, if not to work with mfg. exclusive-class peripherals). It has to be able to a whole bunch of stuff, hard stuff like scheduling for all the peripherals. If this custom host is also to be a peripheral of say a computer or other host, it has to deal with bridging between the other host and the peripherals connected to it. It has to intervene on every transaction. If you want any kind of throughput you have to have a pretty heavy duty microcontroller to do all that work.
Then there is the issue of drivers. The host has to have native drivers for all the peripherals it is to support. When the peripheral is plugged in it has to negotiate with a driver that knows how to talk to it. The host can't ID a device that it doesn't have a driver for. So if you had a camera, a printer and some weird host in between, that host would have to support both devices with drivers just to pass data between them. Do you think the scanner and camera manufacturers are going to provide drivers for every propietary host OS? It's hard enough to get drivers for Mac/Win/Linux/Unix OSs. In FireWire only the two devices that are communicating need to support a common protocol, since any other device in the ring or star would just be passing around the raw data and doesn't have to support each device.
So, in other words, her brother is a dumbass...
Not every company is a cluster of drones that merely 'do what they are told to do with tools they are given'. Some places actually allow their employees to think for themselves and make decisions. Some places encourage diversity and experimentation.
Security concerns, though obviously necessary to some degree, are commonly abused as an excuse for needing to control people. But usually the need to control others has little to do with security or productivity, but instead is all about ego or other self-interests of managers.
The role of an administrator is to deliver and maintain whatever services are appropriate in a given environment as defined by the policy makers.
It may be that in your work environment, the policy, for some unknown reason, is to limit people's creativity and to eliminate their individual power. So the admin's job is then to deliver and maintain straight jackets and blinders for all employees.
I feel sorry for the people that must work in such a stifling environment. I imagine that not having Rendezvous enabled devices is probably the least of their worries.
This is just outright bullshit. Why do people make up shit like this?
Apple has already developed and released the library code and even example client application code specifically targeted at Posix, Win32 and VxWorks systems as well as OS 9 and OS X. It's on the Public Source website. And all the portable stuff is all in C. The only objective-C stuff are the parts that are specifically targeted at OS X development.
And what exactly is 'PPC only code in objective-c'. Do you even know what code is?
I've only read a bit about it, but as far as I understand it, Rendezvous systems only broadcast when they first come on line. They broadcast - 'Here I am and here are my services'. At that point all the other machines on the net cache that info. Then they broadcast a 'who else is out there' message' so that they can sync up with other machines that booted previously. If any new service comes on line after bootup, only the info for that new service is broadcast, and only once. So, once a network is set up, there are no 'continuous' broadcasts to clog the network. I believe a system can broadcast a message to tell the net to resync at any time, but that is not normally required and shouldn't happen very often.
One of the reasons why Apple systems became so popular in the 80's was because of this type of technology that they developed (i.e. AppleTalk Name Binding Protocol). A small publishing business could take a few Macs and a LaserWriter and plug them together using simple cabling and magically the printer just appeared in everyone's Chooser. No print servers required, no DNS, no DHCP. It all 'just worked' the way people needed and wanted it to work.
Since then, networks have gotten more pervasive, and the kinds of peripherals available are much greater and more sophisticated than just printers. So Apple learned from their mistakes (e.g. the chattiness of AT), updated for new types of peripherals and networking requirements and essentially developed (with other peer companies) a next generation of AppleTalk NBP, and they call it Rendezvous/ZeroConf.
Microsoft has simililar technology already in SMB. But most would agree that it is very hard to set up without significant technical expertise and of course it is proprietary, among other well documented limitations.
What is so annoying in threads like this is that so many people just make shit up with a predisposed biased perspective because Apple had something to do with it, and assume Apple can't do anything right. And then so many other people just run with the crap. They assume that some idiot made up some stupid protocol and that there was no thought process and no peer review. They never read the docs and talk about real information. They can't imagine that some smart people may have actually come up with a cool idea, thought about the potential issues and tradeoffs, and solved them as best as anyone could. Luckily there are a few people that try to comat the crap, but most just ignore the real information and continue on spouting the crap, because they really just want to bash.
Just wait a year or so. Rendezvous will be ubiquitous. And people will be benefitting from it and wonder how they ever lived without it. Apple will have lead the way, yet again. And Windows and Linux users will benefit from it just as much as Apple users.