you may fail to compare the product on a open basis (despite that I am sure many of you will deny you are doing this, you will at the same time openly declare that 'GIMP should follow the conventions in PhotoShop because it is the current dominant application')
Repondants then (of course) go on to put forward the case that they are not being one sided and that they are not simply coming from the perspective of an 'Adobe user' and they are really treating both applications on an even footing and that they feel, after fair comparison, that GIMP is simply inferior - then go on to contradict by saying that GIMP should follow the same behavior as Photoshop because that's what they know.
By choosing to express it's faults purely in terms of 'ways it differs from Photoshop' means that no rational person can belive that views expressed on the topic by such posters hold any merit - except when taken as clearly baised opinions by those with a vested interest in maintaing the status quo.
Rather than reply to individual posters all I can do is shake my head at the all-to-predictable lack of vision and Fear Uncertainty and Doubt by users in face of moving away from the methods Adobe has foisted upon them.
This behaviour has been happening online almost since Usenet's inception - with users being afraid of moving from one environment to the next - to the extend that they even defend faults in the current system by decrying them as 'standards' - only to find they are made redundant by more flexible users and those approaching the products from a fresh and untainted perspective. The same arguments have been repeated time and again in the software world and if you know the history of such arguments then the outcome becomes very clear.
I think the failure (of at least one respondent) to see that something as basic as an Aqua based port as an important stepping stone to adoption is a clear demonstration of the lack of vision to which I have alluded. Quite simply, many more users are going to experience the product if an Aquafied version is released, even if it did not entirely behave within the conventions of Mac OS X's Inspector based UI (which it should, but for a product of this nature need not be a priority).
Additionally, in response to another posts, the differences in UI with Film Gimp (or CinePaint - the new name change is not yet complete) are not nearly as significant as some would mislead users to believe - the majority of the interface (such as selectors) are actually identical in both.
You may be afraid of change you may fail to compare the product on a open bases (despite that I am sure many of you will deny you are doing this, you will at the same time openly declare that 'GIMP should follow the conventions in PhotoShop because it is the current dominant application'), but you will simply be made irrelevant by the next generation of designers who have a new fresh approach to design and who are untainted by pre-conceptions about how a particular program should behave, or brand loyalty to Adobe.
I often see this as one difference between good and bad software engineers - while one should not jump on foolish vendor driven bandwagons, a good software engineer is able to adopt a new methodology or language that has an entirely new paradigm and requires a significant re-working of his typical design approach - if he can objectively see that this newer approach is on balance better than his existing approach. A bad engineer, on the other hand, will lack such objectivity and cling defensively to the approach he already understands, because it is more convenient.
Look, as a graphics professional, I have to tell you, GIMP is a nice idea, but is hardly a pro tool.
I disagree, it's used by my many graphics professionals, especially 'film gimp', it's very much a pro tool - for example it can handle file sizes much larger than Photoshop.
This is not because of any lack of features, but because the work flow of it is slow, and clunky.
Actually I think Photoshop is horribly clunky and unintuative too!
I'll certainly grant you that for some things GIMP is less intuative that PhotoShop, but for others I find it's more intuative that Photoshop (Photoshop, though not exactly user hostile, was never a good example of a user friendly application).
Just becase GIMP has a 'different' interface to Photoshop doesn't mean that it's automatically 'worse'. Photoshop is merely Adobe's idea of what a software package should look like - and frankly most Adobe tools have a *hideous* user interface (just look at Acrobat Reader!).
I think a lot of graphic designers have grown up on Photoshop and maybe have forgotten how hard it was to learn how to use Photoshop properly and get use to it. I think this is why many existing graphic designers may not want to switch (developers stuffer from the same issue when new languages come out - there is a productivity trade off to be made by sticking with what you areadly know vs. learning a new technology).
I certainly don't think it's any more clunky (other than the installation) and I *really* wouldn't want GIMP to try and duplicate Photoshop's interface! It may be 'established' but, as I've said, I think it's a bit of a disaster from a Humane Interface POV.
I do think however, that the lack of a Mac OS X Aqua port is slowing it's slow adoption rate amoung established professionals.
'installpkg' is *not* a package management solution (though it could be said to be a 'package installer', in much the same way as rot13 can be said to be 'encryption').
It _is_ an easier way to uncompress and extract a tar file, then automatically run a shell script contained in that file.
It does not check for existing installed copies, dependants, pre-requistes or conflicts when adding/removing software. Which is the point of package management.
That approach may suffice for a personal desktop (as long as your not picky about application integrity), but it entirely inadequate for a corporate workstation or server environment (where the vast majority of the Linux installed user base is).
For example: If you upgrade a library or remove a conflicting (seemingly 'broken') library to satisfy a dependancy then it's very possible to break another application which depends on (or 'uses if present') that library, and you won't even notice until days, weeks or even months down the line (after memory leaks, or intermittent untraceable faults, which can cost huge amounts of loosed revenue while you attempt to trace through the many layers of your infrastructure trying to identify the cause.).
As another example: In any production environment, systems may stay in place for years - if you have no package management there is absolutely no way to gracefully - and in a managed way - upgrade the entire system, short of vast amounts of downtime. After years of hacking and patching, with no package management database, sooner or later you are going to break something and your not going to notice - until it's wasted hours/days/weeks/months of time (and money). You'd also find that your system is full of local, and very probably remote, exploits because you've been unable to keep track of each of the hundreds of different applications and libraries installed on your system.
It is vital to be wary of employing any individual who has enough hubris to believe that they can single handily defeat these issues without the need for system management tools. A good system administrator should have a wide range of tools at his disposal and he should know how to use them, not scorn them in favour of misplaced faith in his abilities.
This is what I mean when I talk about understanding the importance of package management.
Integral package management is essential, in some form or other, for a reliable modern system - is a prerequisite for any production environment (with very rare exception).
'bolting on' package management does not offer you any form of guarantee against conflicts and bugs that occur due to unmatched, or poorly matched, dependencies. It is, in effect, utterly pointless.
Slackware does not have package management. Stating-the-obvious to the original poster (i.e. that you can download and install a package manager) does not change this, and as I said, would ultimately be almost entirely pointless.
Incidentally, I believe you should avoid giving the impression that apt-get is analogous to RPM, it is not. DPKG is the Debian package management system, apt-get is a tool which sit's atop the package management system. There is apt-get for RPM, it would even be possible to run apt-get atop free-bsd's ports system.
As mentioned I'm not a hardware engineer - but I am a systems engineer - and (or so I like to think) not a complete muppet.
If your battery starts acting up, but has been otherwise fine for over a year and half, it's not going to have been your motherboard. Really.
If you installed FIRMWARE on your motherboard then broke the firmware in such a way that you couldn't then flash it and that firmware then caused some interference with the recharding (all of which being massively unlikely and very definately not in my case, or I suspect anyones) - then yes, you would need to do that, but my firmware flashes just fine so no it's not that.
I think you may be getting confused between on board batteries (which hold things such things as the system date and time, and - once a upon an OS long long a go - the background pattern on your desktop). I've certainly heard of unscrupulous sales weasles telling people their computers (e.g. iMac's) have 'expired' and they need to get new ones when this happens, but in reality even this can be replaced (for the cost of a new battery, which costs all of around $5 from your local PC hardware store).
oh wait, two years old and you're f'd
In fairness you can buy Apple Care anytime, if you buy a standard minimal extention at purchase time your covered for three years.
I'd *always* recommend this for any iBook or PowerBook (it's not like one of those horrible rubbishy in store insurance rip offs), it may *seem* like a lot but Apple are VERY good at replacing stuff if covered by Apple Care, even when you've done something stupid to abuse your computer. Not much point in it if you have a iMac or Desktop though (unless you have pre-teenage children or are amazingly clumsy;).
Doesn't bother me much, I've now have my PowerBook G4 in a rackmountable Cisco 2500 chassis while I mull over whether to go for a new 12" PB or a 17" PB with DVD burner...Hmmmm......
(Interesting: I've been informed by our local rep they have loads of trouble with the 15" case design - and I can't think that he'd have any reason to lie as he know I'd probably just opt for the smaller 12" instead. The 12" and 17" design certainly seems a lot more sturdy, the 12" in it's iBook like case certainly more so, though I think the screen is a little cramped - think I'll wait till they increase the resolution on it).
My PowerBook G4 battery won't go beyond '84%' charged now.
While this may well be an 10.2.4 issue, I'm thinking it's very more likely to be due to the age of the battery (I've had my origional G4 'Book for 2 years now and I've been overdue for a replacement for a while).
Now guessing randomly.........
Caution: Just blowing smoke out my ass...
It seems unlikley but it *may* be that 10.2.4 is reporting the charge of the battery more correctly than previous releases? Could it actually be highliting that your battery charge is not as high as it should be if it was a new battery?
Um, yeah, the *REASON* I use VirtualPC (for DOS to access accounting no less -- which I have ZERO intention on replacing anytime soon)... was to get AWAY from Microsoft.
All together now....Change is good.
Functionality that re-working in a Windows package is non-trivial...
That's where your entire approach to this is going wrong...
You should not simply think of 're-working' the software (in the sense of replicating the way the application behaves), you analyze it and see how it could be better done differently. With something so old that it was implimented in DOS it's all but beyond doubt that you'll need to look at re-inventing the solution.
Times change - accounting practices and ways of doing business evolve.
and NO Windows package can handle our payroll and jobcosting needs/wants.
While I agree that the majority of off the shelf accounting solutions are very poor - never the less: tosh and piffle. And I say this as someone who's just spent 12 months designing and developing the accounting libraries in a commercial software package.
Unless you have trivial and extremly common requirements, no one out there is going to have a solution that does exactly what you want. You need to build a solution that suits *your situation*, using Visual Basic and Access, or Perl and XML, or Java and SQL - whatever suits your needs best, but it should leverage new technolgies and approaches to business and accounting that your existing solution cannot take advantage of, and of course it should be built with the next wave of software development in mind, so that you don't need to throw out all your old code next time you upgrade (Visual Basic, Java and Perl all being good for this).
The focus should be on thinking about applications working collaboratively together in an efficent, user friendly, and time and cost savinging manner - in other words - How can I do business better?
Modern programming languages, graphical interfaces, XML and SQL databases are not just industry hoopla - large modern companies have moved away from DOS based applications and embraced these new technologies not for fun but for profit.
Those who resist change simply because they are frightened of it, or who lack the vision to see the the scope for better alternatives, will see their organization slowly wither until it is replaced or made irrelevant.
I'm certainly not professing to be a great hacker, and I don't think people in that category would use that term to desribe themselves.
However...
Not bothering to spend the time working out why a given string crashes an xterm does not mean you are not a great hacker, let alone that you will never be one.
All it means is there was something else you would rather do instead. Which is not a bad thing.
Obviously, you can't fix every software bug in the world on your own - and clearly the best way to deal with them is not to try and fix them all personally, so another approach is needed.
To put it another way:
If everybody spent time trying to fix obscure bugs in other people's code while still trying to write their own software, all development would grind to a halt - developers would spend loads of time pouring over and trying to understand documentation for libraries and API's and going line by line through other people's, very possibly krufty, code - instead of spending time working on solving their own bugs.
If I found such a bug, I'd be likely to contact the author informing him (and provding some details as to why), and go back to fixing *my* bugs.
Although it's no bad thing to debug and fix bugs in other poeple's code if you have some free time and no projects of your own, it's simply far more logical and efficent to spend time fixing your own bugs.
PS: FWIW, IMHO, 'it' is simply equal lashings of time and effort and a dollop of hubris to taste, served on a bed of sufficent basic intelligence. The 'time' and 'effort' ingredients being the hardest to come across.
I think your basic point is valid - I've been using Linux for ~8 years now so most of my perceptions are colored by seeing these distributions evolve.
Though, as a statement in it's own right, it is fair to say that Mandrake is actually 'based on' Red Hat.
So don't equate Mandrake with Redhat.
Well erm I didn't....
PS: Please learn to split sentences into paragraphs, I'm not being a grammer natzi, it's just very frustrating to see people not bother and you happen to be the second or third follow up poster not to use single return in your post.
Trying to deduct the desktop's market share from distribution share is ridiculous
That's why what I actually said was:
Anaecdotally - even when you include Mandrake's slight predisposition towards KDE - this puts GNOME's market share at ~ 43.5% and KDE's at ~ 29%.
In content this was quite clear - when you try to take it out of context it makes little sense - when you take it out of context and deliberatelty choose not to quote the entire sentence (so that you can twist the statement to form an argument around it) it makes even less sense.
It was with reference to market share within the distribution sector, was clearly in context, and remains entirely valid and qualified commentary.
Redhat choses to use Gnome while most of the "Pure" distros like KDE as do I
Painting a picture that it's only Red Hat who like GNOME and that everybody else uses KDE is entirely false.
According to http://counter.li.org/reports/machines.htm, which is just about the most reliable source of information on the subject (due the lack of actual retail figures it's very difficult to count accurately), the most popular core distributions are*:
- Red Hat (~ 29%) - Debian (~ 14.5%) - SuSE (~ 11.5%) - Slackware (~ 11%)
It should be noted that Mandrake is the second most popular distribution of all with over 17.5% market share, though it is not a 'core' or 'pure' distribution as it is based on Red Hat.
* = These figures are taken for a random sampling of 110,000 GNU/Linux users.
Out of these distributions:
- Red Hat - primarily supports GNOME - Debian - primarily supports GNOME - SuSE - primarily supports KDE - Slackware - no notable preference exhibited
Anaecdotally - even when you include Mandrake's slight predisposition towards KDE - this puts GNOME's market share at ~ 43.5% and KDE's at ~ 29%.
With all of these distributions you can obtain GNOME packages or opt to use the GNOME desktop. There is clearly no case to be made that 'core' distributions choose to use KDE to GNOME or even prefer KDE to GNOME, if anything, GNOME seems to have greater market share, not less.
In my opinion, Gnome is turning into the Frankenstein of the open sourced world.
It should be noted that GNOME and KDE are NOT trying to meet entirely the same goals!
KDE works very well 'out of the box' - all the applications are tightly integrated and it works with little fuss as most of the core components are built and written by a core set of KDE developers.
GNOME however, has become a vastly more ambitious project, it is about building a scaleable, flexible, and to some degree language agnostic graphical environment. It is perhaps not surprising that someone might think it has become a Frankensein product - but that is to misunderstand the point of GNOME.
GNOME is a platform for developing and rolling out great best-of-breed applications from disparate developers - software such a GIMP, Gnumeric, Abiword and Nautilus - having them interoperate with each other - and, most importantly - having them interoperate with the user and the desktop environment in a consistent and user focused way. The fruits of this are visible clearly in most current release of GNOME.
GNOME is being developed with long term goals of usability and expandability in mind. It's not just about creating a desktop for the here and now - to borrow a phrase being used recently by Sun - it's about building a product that can "stand the test of time", an expandable product the developers can be proud of and an environment that others will want to build their applications around.
The current incompleteness of GNOME means that many users will prefer the convenience and tight integration of KDE at present - KDE certainly better meets many of the shared GNOME/KDE goals, like the provision of a useful default set of software tools and a coherent control panel. In such an imperfect world it's certainly important for users to have choice - but with regard to the future and long term desktop dominance I belive GNOME is a much more likely canidate than KDE.
This is just a user friendly interface to make mounting idisk WebDav volumes easier for users.
WebDav volume support is something that has been built in to Micrsoft Windows since Windows 98 (and is avalible under Windows 95 if you install MS IE 4.0).
It's not 'beta', it's something that's been supported under Windows for the last 5 years.
The volume is not propriatory in any way, it has not been 'embraced and extended' by Apple.
This is a WebDav IETF working group: http://ftp.ics.uci.edu/pub/ietf/webdav/ ( Actually there are no less than three seperate working groups working on WebDav!)
There are also a couple of RFC's on WebDav: http://www.ietf.org/rfc/rfc2518.txt http ://www.ietf.org/rfc/rfc3253.txt
There are open source utilties for dealing with serving (mod_dav for Apache) and mounting (cadaver) WebDav volumes - it's fair to say that it's assumed Linux, BSD and other Unix users are knowlegeable enough to work out that they can go to freshmeat.net (or Google) and search for the term WebDav.
You can find a list of WebDav related utilites at http://www.webdav.org/.
It should also be pointed out that you don't even need this utility to mount iDisks under Microsoft Windows 98 or newer (or even Windows 95, with MS IE 4.0 IIRC) - the OS supports mounting FTP and WeDav volumes as mapped drives out of the box, this is mearly a slightly more user friendly interface (which will no doubt be a boon to Macintosh users who rarely interact with Microsoft Windows based PC's).
You can use "Advisory Locking" (flock()) or "Mandatory Locking" (fcntl() - or lockf(), a front end to fcntl()).
The advantage of Mandatory locking is that you can choose to lock parts of a file (and leave other parts of it still open to be written to). It also gives you a _fully_ exclusive lock on a file, buy blocking read()/write() systems calls - this is both a blessing and a curse and should be used wisely.
Advisory locking, however, is much more efficent and is widely supported on all Unixes - unlike Mandatory locking which is not (BSD systems tend to support it out of the box, it's an option with Linux, but much more rarely used - vanilla Red Hat or Debian systems tend not to support it IME).
Mac OS X developers should note Apple strongly recommend only using Advisory locking and not Mandatory locking.
Sorry for shouting, but it can be a big deal:-). The issues with Mandatory locking are that it's not supported on all operating systems, and that it's ability to give a truly exclusive lock on a file leads to abusive usage by developers locking files in an abusive - overly harsh (i.e. not even allowing other applications to _read_ the file) - way (not be confused with flocks() ability to simply 'flag' that there is an exlcusive lock).
I would caution anyone NOT to use Mandatory locking unless they are sure they have a good reason for doing so as I've had problems porting small apps (even Perl scripts!) written by people who've used Mandatory locking when they shouldn't have, it's not difficult to fix, but it can be a pain to track down.
Due the previous behaviour of Mac OS's file open behaviour I can forgive old school Mac developers from making this mistake (many have a lot on their plate just moving software to Mac OS X) but for Unix developers I think it's pretty inexcusable to screw up completly (by using fcntl() in appropriately or by not checking for advisory locks with flock()).
Important point:
If you DO use Mandatory locking you should _always_ check for the existing of advisory locking with flock() *first!*. I think Apple have a man page or technote on this somewhere but it's a big deal if you've ever had your files clobbered by some oaf of a program that doesn't pay attention to Advisory locking:-)
If you're hitting your proc limit on an FTP server before your bandwidth limit, you either have a really big pipe or a really shitty server.
Well I'm used to running servers with reasonable bandwidth (single and multiple Gig fibre interfaces), it's what I do for a living. But you can hit OS limits using FTP with any typical server with a 100 MB interface that's getting decent usage (after all that's only going to give you 4 - 6 Mbps which is _not_ a lot for a file server), but it depends on your users and their connection speeds.
It's not like you have to be serving large amounts of files for this to be true either - it's true for small scale just as it is for big scale operations. You get a benifit from using HTTP no matter what size operation you are running.
This is why many serious mirrors now prefer users to download via HTTP. Some sites even only offer HTTP downloads. It's all driven by the bottom line - using HTTP is just less overall overhead than FTP (server load, bandwidth), and overhead costs money. If you think some of these big download sites are fools and clearly don't understand what they are doing, go tell them. You clearly know much more about it that they do (the poor fools!).
As for limiting traffic by controlling how many users can log in to your at once - I suggest you use traffic shaping - do not simply limit the max number of users who can log in. That should be a last resort to prevent your system running away if something goes horribly awry. There is so much obviously wrong with the idea of just limiting the number of concurrent FTP sessions it's just not funny.
As for you taking offence to my LART:
and I'm not stupid or in need of a change of mind frame because I disagree with you
It seems I need to remind you that *you* where the one who stated in your previous post:
For the record, that is a naive, and possibly flat stupid comment.
Ahem.
And as for:
and I can use technical information to backup my disagreement.
That's not at all what I've just seen you demonstrate. I don't think you really have much practical knowledge of the topic at all.
I would envisage any regulation as being applied only to corporations offering a VoIP service, where I think regulation would be welcome as it is in the consumers interest (and consumers are both individuals and corporations and corporations have a very large vested interest in getting a reliable service with an accountable provider).
It may also cover (as it already does in many areas of the world today to some extent) hardware devices that you plug into the network (i.e. in the UK all devices plugged in to your phone socket (Telephones, Modems, Answering Machines) must BABTA approved, to prevent personal injury to you, other telecoms system users or telecoms engineers).
At the moment there are many software based phone interfaces that work via a modem, they are not regulated (and as far as I am aware there is no legislation either in the USA or the UK requiring them to be regulated - even if there is they are still not actually being regulated:-). VoIP software on your PC is no different. There is no reason or precedent to think that VoIP client software is likely to come under scrutiny.
Instead, I predict (rather uninspiringly) that carrier VoIP equipment (physical hardware for connecting to PSTN) will continue to be regulated and we are likely to see some addition regulation governing service provision (particularly with regard to data protection and unsolicited commercial usage - most probably extending existing users rights to voice calls that terminate or originate with a VoIP session[1] - and with regard to service quality and commercial obligations when connecting VoIP calls to PSTN).
[1] Many carriers already tunnel calls over VoIP, especially international calls, and you can't always be sure if a long distance call is or isn't using VoIP so it's likely any legislation would focus on the termination and/or origin of the call. Ideally I'd be interested to see regulators to make the bill more generic and extend consumer rights and protection's to other forms of electronic communication, but I suspect that is a can of worms few are willing to open.
I'm included to think that commercial provision to companies and end users of such a service should require regulation to protect consumers against fraudulent and inexcusably poor quality providers (who will be both individuals and other companies).
This could even be part of a larger consumer rights act governing the way companies do business on line, with specific clauses and amendments for particular industries such as telecoms regulation (though such an act would have be be at Federal level in the USA and at European Union level Europe in order for it be effective and not suffer from regional loopholes).
(While of course I appreciate the internet is global much online business is conducted within national or eurozone boundaries which is why it would be worth investing time in such a bill.)
However...I'd like to think (and this is possibly just wishful thinking:-) that my dedicated VoIP phone of the future will be able to talk to the internet, my computer, PDA or mobile and obtain a list of allowed callers and only let certain numbers though (and give other users voicemail). While this is possible at present with Caller ID and PC software I hope it will be standard in "the world of tomorrow!".
*Really* neat features would be:
- Ability to check for black listed caller ID's in real time (ala MAPS/ORBS (only without Alan Brown:)).
- Ability to take a number, connect to something like the W3C's vision of a Semantic Web and search and find a match for the the number - and so obtain the nature - of the business calling.
This way you could only let certain types of companies through, while blocking others - i.e. always block banks and credit card companies, apart from my own bank and credit card company and always block companies like double glazing firms (unless I've said I'm expecting a call back from a particular company).
If the caller was of "unknown" origin I'd like to be able to leave a brief recorded message telling them that if this is not an unsolicited call from a commercial entity to say 'leave a message' to leave a message on voicemail and I'll call you back (and warning them that if this was a commercial unsolicited call I'd prosecute the company who left the message).
No I don't have the two confused (though this should be clear from my post), partly (but not entirely) I was explaining (or at least trying to) that - from a joe user perspective (i.e. the perspective of the poster who started this thread) why users - of all experience levels - often prefer downloading over HTTP.
The basic idea being that if I am shown two download links on a site, which one do I click - the FTP or HTTP, well I would tend to opt for HTTP (unless my connection was poor or the download was very large).
This is because it's rare you see an 'HTTP' busy message when downloading a file (if you can get to the web site that's not so likely!) where as FTP server too busy messages are not nearly so rare, in fact they can be annoyingly frequent.
But that's just from a user perspective, and which is why many users learn to 'avoid' FTP links for downloads unless they have do (and some joe users don't even know really know why, they just learn from past experience from getting 'server too busy message' when clicking on FTP downloads so they stick with HTTP from then on.)
Quite apart from that (though this is related to why you see so many 'Server Busy' messages) I stated the following:
HTTP is faster than FTP as a transfer protocol. It generates less traffic (and uses less CPU overhead) which means downloads end quicker.
Because of this you hit server limits (like bandwidth, on the number of open threads, the number of open file descriptors, cpu utilisation, etc.) much quicker when users are connecting via FTP as opposed to HTTP.
This is because the very requirements of the FTP protocol are more demanding than the HTTP protocol (for a start, FTP requires twice the number of TCP connections as HTTP - unless you are using passive FTP).
It means it's simply not possible to serve as many downloads via FTP as via HTTP on the same system.
Cry Muppet! and let slip the observations of the-bleeding-obvious!
LART LART LART
For the benefit of you (and other semiliterate posters who can't grok something unless it's explained in small words) I think you'd benefit from reading this again:
Additionally the CPU overhead generated by FTP connections also causes many sites to limit the number of users who can connect, which often results in 'busy sessions', something much rarer with HTTP (as HTTP servers typically have very high thresholds for the number of concurrent connections they will support). The overhead on a server of a user downloading a file over FTP is much greater than that of a user downloading the same file over HTTP.
Once you actually understand how parse that, let's skip on a bit (I don't want to repeat my entire post) and read this:
This may be partly due to poor FTP server configuration defaults and/or poor administration, but they cannot shoulder all the blame.
So clearly I do understand the difference between the configuration of a given server and the protocol.
Now read this (and note the emphasis, if your having too much trouble understanding all of it at once):
Although FTP is of course theoretically more reliable than HTTP, in practice, because of 'Server busy: Too many users' messages combined with the speed and reliability of modern connections (which in turn makes HTTP more reliable) mean the reverse is often the case from a user perspective - which is what I think the poster is getting at.
Now did you not understand any of that? Logically I would not be able to give such commentary and in such level of detail without knowing the elementally basics which you've so inelegantly attempted to express.
Please try and grasp this basic point:
The most important thing you DON'T seem to be getting is:
The FTP protocol requires both more bandwidth and a notably more complex server than HTTP does.
Which means, ipso facto:
That allowing someone to download via FTP uses MORE bandwidth and MORE CPU time than using HTTP.
At a maintainable given speed, it is possible to serve more files on a server via HTTP that via FTP. Additionally the HTTP downloads will end slightly quicker (most notable with small downloads around the size the article poster indicated they would be serving) because of the lower overhead.
And finally (quote, NOT from me):
Just wait 'til you get an HTTP site that gets maxed on traffic - HTTP server too busy messages really suck... sometimes you don't even get the connection.
I've managed sites that take millions of hits a day and servers with tens of thousands of individual web sites.:-P
Slashdot Mirror
You 'KNOW for a CERTAIN FACT' (your emphasis) that Comcast sold your email address?
I don't think you do 'know for a certain fact' that Comcast sold your email address.
I don't see how you deduce that just from the fact that you'd never checked that mailbox before and the first time you did their was spam in it?
That's not 'knowing for a certain fact', that's really just you guessing. There are quite a few reasons why what you've experienced can happen.
I will note that I said this:
you may fail to compare the product on a open basis (despite that I am sure many of you will deny you are doing this, you will at the same time openly declare that 'GIMP should follow the conventions in PhotoShop because it is the current dominant application')
Repondants then (of course) go on to put forward the case that they are not being one sided and that they are not simply coming from the perspective of an 'Adobe user' and they are really treating both applications on an even footing and that they feel, after fair comparison, that GIMP is simply inferior - then go on to contradict by saying that GIMP should follow the same behavior as Photoshop because that's what they know.
By choosing to express it's faults purely in terms of 'ways it differs from Photoshop' means that no rational person can belive that views expressed on the topic by such posters hold any merit - except when taken as clearly baised opinions by those with a vested interest in maintaing the status quo.
Rather than reply to individual posters all I can do is shake my head at the all-to-predictable lack of vision and Fear Uncertainty and Doubt by users in face of moving away from the methods Adobe has foisted upon them.
This behaviour has been happening online almost since Usenet's inception - with users being afraid of moving from one environment to the next - to the extend that they even defend faults in the current system by decrying them as 'standards' - only to find they are made redundant by more flexible users and those approaching the products from a fresh and untainted perspective. The same arguments have been repeated time and again in the software world and if you know the history of such arguments then the outcome becomes very clear.
I think the failure (of at least one respondent) to see that something as basic as an Aqua based port as an important stepping stone to adoption is a clear demonstration of the lack of vision to which I have alluded. Quite simply, many more users are going to experience the product if an Aquafied version is released, even if it did not entirely behave within the conventions of Mac OS X's Inspector based UI (which it should, but for a product of this nature need not be a priority).
Additionally, in response to another posts, the differences in UI with Film Gimp (or CinePaint - the new name change is not yet complete) are not nearly as significant as some would mislead users to believe - the majority of the interface (such as selectors) are actually identical in both.
You may be afraid of change you may fail to compare the product on a open bases (despite that I am sure many of you will deny you are doing this, you will at the same time openly declare that 'GIMP should follow the conventions in PhotoShop because it is the current dominant application'), but you will simply be made irrelevant by the next generation of designers who have a new fresh approach to design and who are untainted by pre-conceptions about how a particular program should behave, or brand loyalty to Adobe.
I often see this as one difference between good and bad software engineers - while one should not jump on foolish vendor driven bandwagons, a good software engineer is able to adopt a new methodology or language that has an entirely new paradigm and requires a significant re-working of his typical design approach - if he can objectively see that this newer approach is on balance better than his existing approach. A bad engineer, on the other hand, will lack such objectivity and cling defensively to the approach he already understands, because it is more convenient.
Look, as a graphics professional, I have to tell you, GIMP is a nice idea, but is hardly a pro tool.
I disagree, it's used by my many graphics professionals, especially 'film gimp', it's very much a pro tool - for example it can handle file sizes much larger than Photoshop.
This is not because of any lack of features, but because the work flow of it is slow, and clunky.
Actually I think Photoshop is horribly clunky and unintuative too!
I'll certainly grant you that for some things GIMP is less intuative that PhotoShop, but for others I find it's more intuative that Photoshop (Photoshop, though not exactly user hostile, was never a good example of a user friendly application).
Just becase GIMP has a 'different' interface to Photoshop doesn't mean that it's automatically 'worse'. Photoshop is merely Adobe's idea of what a software package should look like - and frankly most Adobe tools have a *hideous* user interface (just look at Acrobat Reader!).
I think a lot of graphic designers have grown up on Photoshop and maybe have forgotten how hard it was to learn how to use Photoshop properly and get use to it. I think this is why many existing graphic designers may not want to switch (developers stuffer from the same issue when new languages come out - there is a productivity trade off to be made by sticking with what you areadly know vs. learning a new technology).
I certainly don't think it's any more clunky (other than the installation) and I *really* wouldn't want GIMP to try and duplicate Photoshop's interface! It may be 'established' but, as I've said, I think it's a bit of a disaster from a Humane Interface POV.
I do think however, that the lack of a Mac OS X Aqua port is slowing it's slow adoption rate amoung established professionals.
'installpkg' is *not* a package management solution (though it could be said to be a 'package installer', in much the same way as rot13 can be said to be 'encryption').
It _is_ an easier way to uncompress and extract a tar file, then automatically run a shell script contained in that file.
It does not check for existing installed copies, dependants, pre-requistes or conflicts when adding/removing software. Which is the point of package management.
That approach may suffice for a personal desktop (as long as your not picky about application integrity), but it entirely inadequate for a corporate workstation or server environment (where the vast majority of the Linux installed user base is).
For example: If you upgrade a library or remove a conflicting (seemingly 'broken') library to satisfy a dependancy then it's very possible to break another application which depends on (or 'uses if present') that library, and you won't even notice until days, weeks or even months down the line (after memory leaks, or intermittent untraceable faults, which can cost huge amounts of loosed revenue while you attempt to trace through the many layers of your infrastructure trying to identify the cause.).
As another example: In any production environment, systems may stay in place for years - if you have no package management there is absolutely no way to gracefully - and in a managed way - upgrade the entire system, short of vast amounts of downtime. After years of hacking and patching, with no package management database, sooner or later you are going to break something and your not going to notice - until it's wasted hours/days/weeks/months of time (and money). You'd also find that your system is full of local, and very probably remote, exploits because you've been unable to keep track of each of the hundreds of different applications and libraries installed on your system.
It is vital to be wary of employing any individual who has enough hubris to believe that they can single handily defeat these issues without the need for system management tools. A good system administrator should have a wide range of tools at his disposal and he should know how to use them, not scorn them in favour of misplaced faith in his abilities.
This is what I mean when I talk about understanding the importance of package management.
Integral package management is essential, in some form or other, for a reliable modern system - is a prerequisite for any production environment (with very rare exception).
'bolting on' package management does not offer you any form of guarantee against conflicts and bugs that occur due to unmatched, or poorly matched, dependencies. It is, in effect, utterly pointless.
Slackware does not have package management. Stating-the-obvious to the original poster (i.e. that you can download and install a package manager) does not change this, and as I said, would ultimately be almost entirely pointless.
Incidentally, I believe you should avoid giving the impression that apt-get is analogous to RPM, it is not. DPKG is the Debian package management system, apt-get is a tool which sit's atop the package management system. There is apt-get for RPM, it would even be possible to run apt-get atop free-bsd's ports system.
In true honesty I don't really see a need any longer for virtual PC except for Mac users that are used to a PC that want to keep using windows.
As stated in the review it's very useful for developers (like the review, and like me). You did read the review didn't you?
I would almost keep a *gasp* windows machine around if it were that important to me
Oh yeah *two* laptops or *one*. Let me think...
OR, I would quit being lazy and learn something new.
How about you quit being lazy and read the review?
Anyways, I remember the "rumors" of a MS Windows Release for PPC
A Rumour?
Windows NT for PPC was offically released!
NB: It was never ported to run on Macintosh hardware and was never indended to.
and I also remember "rumors" of Mac OS for x86.
Again - You think this is a Rumour?
Mac OS was ported to x86 as part of the StarTrek project, go Google FFS.
Additionaly there was Rhapsody of course, aka OpenStep with a menubar (and OpenStep ran on x86 long before it was ported to PPC).
it will turn out that you need a new logic board
;).
The motherboard - No! Really, no it's not!
As mentioned I'm not a hardware engineer - but I am a systems engineer - and (or so I like to think) not a complete muppet.
If your battery starts acting up, but has been otherwise fine for over a year and half, it's not going to have been your motherboard. Really.
If you installed FIRMWARE on your motherboard then broke the firmware in such a way that you couldn't then flash it and that firmware then caused some interference with the recharding (all of which being massively unlikely and very definately not in my case, or I suspect anyones) - then yes, you would need to do that, but my firmware flashes just fine so no it's not that.
I think you may be getting confused between on board batteries (which hold things such things as the system date and time, and - once a upon an OS long long a go - the background pattern on your desktop). I've certainly heard of unscrupulous sales weasles telling people their computers (e.g. iMac's) have 'expired' and they need to get new ones when this happens, but in reality even this can be replaced (for the cost of a new battery, which costs all of around $5 from your local PC hardware store).
oh wait, two years old and you're f'd
In fairness you can buy Apple Care anytime, if you buy a standard minimal extention at purchase time your covered for three years.
I'd *always* recommend this for any iBook or PowerBook (it's not like one of those horrible rubbishy in store insurance rip offs), it may *seem* like a lot but Apple are VERY good at replacing stuff if covered by Apple Care, even when you've done something stupid to abuse your computer. Not much point in it if you have a iMac or Desktop though (unless you have pre-teenage children or are amazingly clumsy
Doesn't bother me much, I've now have my PowerBook G4 in a rackmountable Cisco 2500 chassis while I mull over whether to go for a new 12" PB or a 17" PB with DVD burner...Hmmmm......
(Interesting: I've been informed by our local rep they have loads of trouble with the 15" case design - and I can't think that he'd have any reason to lie as he know I'd probably just opt for the smaller 12" instead. The 12" and 17" design certainly seems a lot more sturdy, the 12" in it's iBook like case certainly more so, though I think the screen is a little cramped - think I'll wait till they increase the resolution on it).
My PowerBook G4 battery won't go beyond '84%' charged now.
:/
:)
While this may well be an 10.2.4 issue, I'm thinking it's very more likely to be due to the age of the battery (I've had my origional G4 'Book for 2 years now and I've been overdue for a replacement for a while).
Now guessing randomly.........
Caution: Just blowing smoke out my ass...
It seems unlikley but it *may* be that 10.2.4 is reporting the charge of the battery more correctly than previous releases? Could it actually be highliting that your battery charge is not as high as it should be if it was a new battery?
Or is that bullshit?
(Don't ask me, I'm just a software monkey
Um, yeah, the *REASON* I use VirtualPC (for DOS to access accounting no less -- which I have ZERO intention on replacing anytime soon) ... was to get AWAY from Microsoft.
...
All together now....Change is good.
Functionality that re-working in a Windows package is non-trivial
That's where your entire approach to this is going wrong...
You should not simply think of 're-working' the software (in the sense of replicating the way the application behaves), you analyze it and see how it could be better done differently. With something so old that it was implimented in DOS it's all but beyond doubt that you'll need to look at re-inventing the solution.
Times change - accounting practices and ways of doing business evolve.
and NO Windows package can handle our payroll and jobcosting needs/wants.
While I agree that the majority of off the shelf accounting solutions are very poor - never the less: tosh and piffle. And I say this as someone who's just spent 12 months designing and developing the accounting libraries in a commercial software package.
Unless you have trivial and extremly common requirements, no one out there is going to have a solution that does exactly what you want. You need to build a solution that suits *your situation*, using Visual Basic and Access, or Perl and XML, or Java and SQL - whatever suits your needs best, but it should leverage new technolgies and approaches to business and accounting that your existing solution cannot take advantage of, and of course it should be built with the next wave of software development in mind, so that you don't need to throw out all your old code next time you upgrade (Visual Basic, Java and Perl all being good for this).
The focus should be on thinking about applications working collaboratively together in an efficent, user friendly, and time and cost savinging manner - in other words - How can I do business better?
Modern programming languages, graphical interfaces, XML and SQL databases are not just industry hoopla - large modern companies have moved away from DOS based applications and embraced these new technologies not for fun but for profit.
Those who resist change simply because they are frightened of it, or who lack the vision to see the the scope for better alternatives, will see their organization slowly wither until it is replaced or made irrelevant.
Damn :/
That's what I was trying to say, but shorter, and included the specifc Larry Wall reference I was thinking when I wrote my reply.
That will teach me to post a followup before reading the already posted replies. <autolart>
I think that's nonsense.
I'm certainly not professing to be a great hacker, and I don't think people in that category would use that term to desribe themselves.
However...
Not bothering to spend the time working out why a given string crashes an xterm does not mean you are not a great hacker, let alone that you will never be one.
All it means is there was something else you would rather do instead. Which is not a bad thing.
Obviously, you can't fix every software bug in the world on your own - and clearly the best way to deal with them is not to try and fix them all personally, so another approach is needed.
To put it another way:
If everybody spent time trying to fix obscure bugs in other people's code while still trying to write their own software, all development would grind to a halt - developers would spend loads of time pouring over and trying to understand documentation for libraries and API's and going line by line through other people's, very possibly krufty, code - instead of spending time working on solving their own bugs.
If I found such a bug, I'd be likely to contact the author informing him (and provding some details as to why), and go back to fixing *my* bugs.
Although it's no bad thing to debug and fix bugs in other poeple's code if you have some free time and no projects of your own, it's simply far more logical and efficent to spend time fixing your own bugs.
PS: FWIW, IMHO, 'it' is simply equal lashings of time and effort and a dollop of hubris to taste, served on a bed of sufficent basic intelligence. The 'time' and 'effort' ingredients being the hardest to come across.
I think your basic point is valid - I've been using Linux for ~8 years now so most of my perceptions are colored by seeing these distributions evolve.
Though, as a statement in it's own right, it is fair to say that Mandrake is actually 'based on' Red Hat.
So don't equate Mandrake with Redhat.
Well erm I didn't....
PS: Please learn to split sentences into paragraphs, I'm not being a grammer natzi, it's just very frustrating to see people not bother and you happen to be the second or third follow up poster not to use single return in your post.
Trying to deduct the desktop's market share from distribution share is ridiculous
That's why what I actually said was:
Anaecdotally - even when you include Mandrake's slight predisposition towards KDE - this puts GNOME's market share at ~ 43.5% and KDE's at ~ 29%.
In content this was quite clear - when you try to take it out of context it makes little sense - when you take it out of context and deliberatelty choose not to quote the entire sentence (so that you can twist the statement to form an argument around it) it makes even less sense.
It was with reference to market share within the distribution sector, was clearly in context, and remains entirely valid and qualified commentary.
Redhat choses to use Gnome while most of the "Pure" distros like KDE as do I
Painting a picture that it's only Red Hat who like GNOME and that everybody else uses KDE is entirely false.
According to http://counter.li.org/reports/machines.htm, which is just about the most reliable source of information on the subject (due the lack of actual retail figures it's very difficult to count accurately), the most popular core distributions are*:
- Red Hat (~ 29%)
- Debian (~ 14.5%)
- SuSE (~ 11.5%)
- Slackware (~ 11%)
It should be noted that Mandrake is the second most popular distribution of all with over 17.5% market share, though it is not a 'core' or 'pure' distribution as it is based on Red Hat.
* = These figures are taken for a random sampling of 110,000 GNU/Linux users.
Out of these distributions:
- Red Hat - primarily supports GNOME
- Debian - primarily supports GNOME
- SuSE - primarily supports KDE
- Slackware - no notable preference exhibited
Anaecdotally - even when you include Mandrake's slight predisposition towards KDE - this puts GNOME's market share at ~ 43.5% and KDE's at ~ 29%.
With all of these distributions you can obtain GNOME packages or opt to use the GNOME desktop. There is clearly no case to be made that 'core' distributions choose to use KDE to GNOME or even prefer KDE to GNOME, if anything, GNOME seems to have greater market share, not less.
In my opinion, Gnome is turning into the Frankenstein of the open sourced world.
It should be noted that GNOME and KDE are NOT trying to meet entirely the same goals!
KDE works very well 'out of the box' - all the applications are tightly integrated and it works with little fuss as most of the core components are built and written by a core set of KDE developers.
GNOME however, has become a vastly more ambitious project, it is about building a scaleable, flexible, and to some degree language agnostic graphical environment. It is perhaps not surprising that someone might think it has become a Frankensein product - but that is to misunderstand the point of GNOME.
GNOME is a platform for developing and rolling out great best-of-breed applications from disparate developers - software such a GIMP, Gnumeric, Abiword and Nautilus - having them interoperate with each other - and, most importantly - having them interoperate with the user and the desktop environment in a consistent and user focused way. The fruits of this are visible clearly in most current release of GNOME.
GNOME is being developed with long term goals of usability and expandability in mind. It's not just about creating a desktop for the here and now - to borrow a phrase being used recently by Sun - it's about building a product that can "stand the test of time", an expandable product the developers can be proud of and an environment that others will want to build their applications around.
The current incompleteness of GNOME means that many users will prefer the convenience and tight integration of KDE at present - KDE certainly better meets many of the shared GNOME/KDE goals, like the provision of a useful default set of software tools and a coherent control panel. In such an imperfect world it's certainly important for users to have choice - but with regard to the future and long term desktop dominance I belive GNOME is a much more likely canidate than KDE.
This is just a user friendly interface to make mounting idisk WebDav volumes easier for users.
WebDav volume support is something that has been built in to Micrsoft Windows since Windows 98 (and is avalible under Windows 95 if you install MS IE 4.0).
It's not 'beta', it's something that's been supported under Windows for the last 5 years.
It's open standard - WebDav.
( Actually there are no less than three seperate working groups working on WebDav!)
p ://www.ietf.org/rfc/rfc3253.txt
/idisk -u username -p password
The volume is not propriatory in any way, it has not been 'embraced and extended' by Apple.
This is a WebDav IETF working group:
http://ftp.ics.uci.edu/pub/ietf/webdav/
There are also a couple of RFC's on WebDav:
http://www.ietf.org/rfc/rfc2518.txt
htt
There are open source utilties for dealing with serving (mod_dav for Apache) and mounting (cadaver) WebDav volumes - it's fair to say that it's assumed Linux, BSD and other Unix users are knowlegeable enough to work out that they can go to freshmeat.net (or Google) and search for the term WebDav.
You can find a list of WebDav related utilites at http://www.webdav.org/.
It should also be pointed out that you don't even need this utility to mount iDisks under Microsoft Windows 98 or newer (or even Windows 95, with MS IE 4.0 IIRC) - the OS supports mounting FTP and WeDav volumes as mapped drives out of the box, this is mearly a slightly more user friendly interface (which will no doubt be a boon to Macintosh users who rarely interact with Microsoft Windows based PC's).
So to answer the questio you posed:
Where's the Linux version?
If you can sucessfully do this:
mount.davfs http://idisk.mac.com/username
The answer is 'already compiled on your system'.
Mmm yes and relevent point on this:
:-). The issues with Mandatory locking are that it's not supported on all operating systems, and that it's ability to give a truly exclusive lock on a file leads to abusive usage by developers locking files in an abusive - overly harsh (i.e. not even allowing other applications to _read_ the file) - way (not be confused with flocks() ability to simply 'flag' that there is an exlcusive lock).
:-)
You can use "Advisory Locking" (flock()) or "Mandatory Locking" (fcntl() - or lockf(), a front end to fcntl()).
The advantage of Mandatory locking is that you can choose to lock parts of a file (and leave other parts of it still open to be written to). It also gives you a _fully_ exclusive lock on a file, buy blocking read()/write() systems calls - this is both a blessing and a curse and should be used wisely.
Advisory locking, however, is much more efficent and is widely supported on all Unixes - unlike Mandatory locking which is not (BSD systems tend to support it out of the box, it's an option with Linux, but much more rarely used - vanilla Red Hat or Debian systems tend not to support it IME).
Mac OS X developers should note Apple strongly recommend only using Advisory locking and not Mandatory locking.
Sorry for shouting, but it can be a big deal
I would caution anyone NOT to use Mandatory locking unless they are sure they have a good reason for doing so as I've had problems porting small apps (even Perl scripts!) written by people who've used Mandatory locking when they shouldn't have, it's not difficult to fix, but it can be a pain to track down.
Due the previous behaviour of Mac OS's file open behaviour I can forgive old school Mac developers from making this mistake (many have a lot on their plate just moving software to Mac OS X) but for Unix developers I think it's pretty inexcusable to screw up completly (by using fcntl() in appropriately or by not checking for advisory locks with flock()).
Important point:
If you DO use Mandatory locking you should _always_ check for the existing of advisory locking with flock() *first!*. I think Apple have a man page or technote on this somewhere but it's a big deal if you've ever had your files clobbered by some oaf of a program that doesn't pay attention to Advisory locking
If you're hitting your proc limit on an FTP server before your bandwidth limit, you either have a really big pipe or a really shitty server.
Well I'm used to running servers with reasonable bandwidth (single and multiple Gig fibre interfaces), it's what I do for a living. But you can hit OS limits using FTP with any typical server with a 100 MB interface that's getting decent usage (after all that's only going to give you 4 - 6 Mbps which is _not_ a lot for a file server), but it depends on your users and their connection speeds.
It's not like you have to be serving large amounts of files for this to be true either - it's true for small scale just as it is for big scale operations. You get a benifit from using HTTP no matter what size operation you are running.
This is why many serious mirrors now prefer users to download via HTTP. Some sites even only offer HTTP downloads. It's all driven by the bottom line - using HTTP is just less overall overhead than FTP (server load, bandwidth), and overhead costs money. If you think some of these big download sites are fools and clearly don't understand what they are doing, go tell them. You clearly know much more about it that they do (the poor fools!).
As for limiting traffic by controlling how many users can log in to your at once - I suggest you use traffic shaping - do not simply limit the max number of users who can log in. That should be a last resort to prevent your system running away if something goes horribly awry. There is so much obviously wrong with the idea of just limiting the number of concurrent FTP sessions it's just not funny.
As for you taking offence to my LART:
and I'm not stupid or in need of a change of mind frame because I disagree with you
It seems I need to remind you that *you* where the one who stated in your previous post:
For the record, that is a naive, and possibly flat stupid comment.
Ahem.
And as for:
and I can use technical information to backup my disagreement.
That's not at all what I've just seen you demonstrate. I don't think you really have much practical knowledge of the topic at all.
Hash, but fair I think.
I would envisage any regulation as being applied only to corporations offering a VoIP service, where I think regulation would be welcome as it is in the consumers interest (and consumers are both individuals and corporations and corporations have a very large vested interest in getting a reliable service with an accountable provider).
:-). VoIP software on your PC is no different. There is no reason or precedent to think that VoIP client software is likely to come under scrutiny.
It may also cover (as it already does in many areas of the world today to some extent) hardware devices that you plug into the network (i.e. in the UK all devices plugged in to your phone socket (Telephones, Modems, Answering Machines) must BABTA approved, to prevent personal injury to you, other telecoms system users or telecoms engineers).
At the moment there are many software based phone interfaces that work via a modem, they are not regulated (and as far as I am aware there is no legislation either in the USA or the UK requiring them to be regulated - even if there is they are still not actually being regulated
Instead, I predict (rather uninspiringly) that carrier VoIP equipment (physical hardware for connecting to PSTN) will continue to be regulated and we are likely to see some addition regulation governing service provision (particularly with regard to data protection and unsolicited commercial usage - most probably extending existing users rights to voice calls that terminate or originate with a VoIP session[1] - and with regard to service quality and commercial obligations when connecting VoIP calls to PSTN).
[1] Many carriers already tunnel calls over VoIP, especially international calls, and you can't always be sure if a long distance call is or isn't using VoIP so it's likely any legislation would focus on the termination and/or origin of the call. Ideally I'd be interested to see regulators to make the bill more generic and extend consumer rights and protection's to other forms of electronic communication, but I suspect that is a can of worms few are willing to open.
This is a very good point.
:-) that my dedicated VoIP phone of the future will be able to talk to the internet, my computer, PDA or mobile and obtain a list of allowed callers and only let certain numbers though (and give other users voicemail). While this is possible at present with Caller ID and PC software I hope it will be standard in "the world of tomorrow!".
:)).
I'm included to think that commercial provision to companies and end users of such a service should require regulation to protect consumers against fraudulent and inexcusably poor quality providers (who will be both individuals and other companies).
This could even be part of a larger consumer rights act governing the way companies do business on line, with specific clauses and amendments for particular industries such as telecoms regulation (though such an act would have be be at Federal level in the USA and at European Union level Europe in order for it be effective and not suffer from regional loopholes).
(While of course I appreciate the internet is global much online business is conducted within national or eurozone boundaries which is why it would be worth investing time in such a bill.)
However...I'd like to think (and this is possibly just wishful thinking
*Really* neat features would be:
- Ability to check for black listed caller ID's in real time (ala MAPS/ORBS (only without Alan Brown
- Ability to take a number, connect to something like the W3C's vision of a Semantic Web and search and find a match for the the number - and so obtain the nature - of the business calling.
This way you could only let certain types of companies through, while blocking others - i.e. always block banks and credit card companies, apart from my own bank and credit card company and always block companies like double glazing firms (unless I've said I'm expecting a call back from a particular company).
If the caller was of "unknown" origin I'd like to be able to leave a brief recorded message telling them that if this is not an unsolicited call from a commercial entity to say 'leave a message' to leave a message on voicemail and I'll call you back (and warning them that if this was a commercial unsolicited call I'd prosecute the company who left the message).
No I don't have the two confused (though this should be clear from my post), partly (but not entirely) I was explaining (or at least trying to) that - from a joe user perspective (i.e. the perspective of the poster who started this thread) why users - of all experience levels - often prefer downloading over HTTP.
The basic idea being that if I am shown two download links on a site, which one do I click - the FTP or HTTP, well I would tend to opt for HTTP (unless my connection was poor or the download was very large).
This is because it's rare you see an 'HTTP' busy message when downloading a file (if you can get to the web site that's not so likely!) where as FTP server too busy messages are not nearly so rare, in fact they can be annoyingly frequent.
But that's just from a user perspective, and which is why many users learn to 'avoid' FTP links for downloads unless they have do (and some joe users don't even know really know why, they just learn from past experience from getting 'server too busy message' when clicking on FTP downloads so they stick with HTTP from then on.)
Quite apart from that (though this is related to why you see so many 'Server Busy' messages) I stated the following:
HTTP is faster than FTP as a transfer protocol. It generates less traffic (and uses less CPU overhead) which means downloads end quicker.
Because of this you hit server limits (like bandwidth, on the number of open threads, the number of open file descriptors, cpu utilisation, etc.) much quicker when users are connecting via FTP as opposed to HTTP.
This is because the very requirements of the FTP protocol are more demanding than the HTTP protocol (for a start, FTP requires twice the number of TCP connections as HTTP - unless you are using passive FTP).
It means it's simply not possible to serve as many downloads via FTP as via HTTP on the same system.
Cry Muppet! and let slip the observations of the-bleeding-obvious!
LART LART LART
For the benefit of you (and other semiliterate posters who can't grok something unless it's explained in small words) I think you'd benefit from reading this again:
Additionally the CPU overhead generated by FTP connections also causes many sites to limit the number of users who can connect, which often results in 'busy sessions', something much rarer with HTTP (as HTTP servers typically have very high thresholds for the number of concurrent connections they will support). The overhead on a server of a user downloading a file over FTP is much greater than that of a user downloading the same file over HTTP.
Once you actually understand how parse that, let's skip on a bit (I don't want to repeat my entire post) and read this:
This may be partly due to poor FTP server configuration defaults and/or poor administration, but they cannot shoulder all the blame.
So clearly I do understand the difference between the configuration of a given server and the protocol.
Now read this (and note the emphasis, if your having too much trouble understanding all of it at once):
Although FTP is of course theoretically more reliable than HTTP, in practice, because of 'Server busy: Too many users' messages combined with the speed and reliability of modern connections (which in turn makes HTTP more reliable) mean the reverse is often the case from a user perspective - which is what I think the poster is getting at.
Now did you not understand any of that? Logically I would not be able to give such commentary and in such level of detail without knowing the elementally basics which you've so inelegantly attempted to express.
Please try and grasp this basic point:
The most important thing you DON'T seem to be getting is:
The FTP protocol requires both more bandwidth and a notably more complex server than HTTP does.
Which means, ipso facto:
That allowing someone to download via FTP uses MORE bandwidth and MORE CPU time than using HTTP.
At a maintainable given speed, it is possible to serve more files on a server via HTTP that via FTP. Additionally the HTTP downloads will end slightly quicker (most notable with small downloads around the size the article poster indicated they would be serving) because of the lower overhead.
And finally (quote, NOT from me):
Just wait 'til you get an HTTP site that gets maxed on traffic - HTTP server too busy messages really suck... sometimes you don't even get the connection.
I've managed sites that take millions of hits a day and servers with tens of thousands of individual web sites.
I agree with your post - though I'd add to that - in saying the less over head required by HTTP makes it even faster that FTP.
(And also that HTTP traffic generates less serverload than FTP).