Indeed, on the face of it the proposal reminds me of range voting. If only each user would voluntarily agree to take less bandwidth than they're able to get, then the net would run more smoothly. But no P2Per would install the upgrade from Microsoft or from his Linux distribution to replace the fast, greedy TCP stack with a more ethical, caring-sharing one that makes his downloads slower.
What I don't understand is why this concerns TCP at all. An ISP's job is surely to send and receive IP datagrams on behalf of its customers. What you do in the higher levels of the protocol stack is up to you; some apps may be using UDP, others SCTP or other TCP replacements. The backoff and error correction of TCP is intended to ensure reliable connections between one host and another, not to somehow manage congestion for the whole Internet. Back in the days when the net was only thirty thousand hosts big and everyone had a competent, public-spirited sysadmin it used to work to insist that everyone change their client software for the greater good. Not now.
If any congestion filtering needs to be applied it should be done at the level of IP datagrams, no matter what they contain. If clients feel that high-priority applications like web browsing or VoIP shouldn't be blocked by P2P traffic, then they can set the priority field accordingly. Of course, this would instantly be defeated if ISPs honour that field too naively; everyone would just set all traffic to the highest priority level. An ISP would have to weight the priorities of a given subscriber based on their historical average, so that someone who sends every packet marked TOP URGENT gets no benefit.
Congestion notification is surely useful, as an additional mechanism to help higher levels of the network stack respond to packets being dropped or delayed lower down. But you can't rely upon users to always honour these voluntary systems. Any mechanism that is voluntary and isn't linked to some kind of metering or charging will be subverted, and probably sooner than you think. So the EFF and others are entirely right to suggest ISPs use metering. As long as the terms of service are clearly defined and you get what you pay for (so no bogus 'unlimited' promises), I don't see anything wrong in that.
What a storm in a teacup. Will anyone except Microsoft shops want to run Microsoft's virtualization product? Will they care that Debian isn't a 'supported platform', whatever that means? It's not as if other Linux versions won't run; just you won't be able to get Microsoft's famously good technical support to help with setting them up.
'...You hadn't exactly gone out of your way to call attention to them had you? I mean like actually telling anyone or anything.'
'But the plans were on display...'
'On display? I eventually had to go down to the cellar to find them.'
'That's the display department.'
'With a torch.'
'Ah, well the lights had probably gone.'
'So had the stairs.'
'But look you found the notice didn't you?'
'Yes,' said Arthur, 'yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of The Leopard".'
Database systems use that sort of thing all the time, telling the kernel not to bother caching their file I/O but send it straight to disk (of course, they have their own cache configured by the database administrator). Typically if it needs to scan table more than the size of available memory, it reads the data from start to finish off the disk but doesn't cache any of it.
My BBC had BASIC 1.0 and it supports named procedures fine. It lacks EQUB and similar assembler directives, which makes it a pain to include literal byte values or strings in your assembly language programs. These were added in BASIC 2.0.
It is not a security flaw to store passwords in plain text - or at least, 'encrypting' them with some fixed algorithm gives no security benefit. At best it's security through obscurity.
In fact, it's surprisingly sensible of Microsoft to recognize this, given the 'compressible encryption' and other non-security security nonsense they provide in other products.
I'm sorry, but *any* system that stores email in a binary database is simply lame.
This is a bit daft; in the end everything is stored in a binary database when it goes to disk. If you trust an database system for storing financial records at your bank, why shouldn't it store your mail? Do you think that Gmail really uses maildirs with one file per message, and good old find+grep for searching?
You're talking about Adaptive Server Anywhere (ASA) but the one that shares a lineage with MSSQL is Adaptive Server Enterprise (ASE). They are different products with different codebases.
I need to run MS SQL server, it's the only one that my company's workflow software will run on.
Have you investigated porting to Sybase? It's pretty similar.
Also our enterprise app is all written in ASP.
Have you looked at Chili!Soft ASP? Or if you're using ASP.NET, Mono?
We also have lots of Exchange users.
Gotta admit, this is harder to migrate from once all your data is locked up in those binary PST files.
But you have a point that many people, yourself included, are stuck with Windows. It wouldn't be easy to migrate. Much more convenient to buy some crappy virus scanner and keep the plates spinning.
Due to one thing and another this results in some hideously malformed HTML, but it has the desired effect (of executing the Javascript) in the major browsers.
How many vulnerabilities would be eliminated if web applications (a) produced valid HTML and (b) validated each page of output before sending it to the browser?
If you think that's too slow, then the validation could be done asynchronously and if a script starts generating invalid pages then it could be temporarily disabled while the administrator investigates.
Anyone who routinely runs Windows using the admin account is an idiot,
Logging in as 'administrator' is a bit silly. However, running as an individual user who has full admin rights is often the only way to do things. I'd love to run as a non-privileged user but the sad fact is that you can't install software without administrator rights, even if you try to put it in your home directory. Other things like debugging also go wrong unless you have admin rights on your PC. By contrast, on Unix systems you rarely need to be root to get work done - you can install your own software in your own directory and not bother anyone else.
Re:Wrong day
on
Happy Pi Day
·
· Score: 3, Informative
YYYY-MM-DD would be better; the different delimiter character avoids confusion with other date formats. This is the standard date and time notation.
'course, if you're making subdirectories on a Unix filesystem, using / is handy.
I was referring to the original statement 'any sufficiently advanced chatbot is indistinguishable from a human'. But there are many more features of human beings than just their intelligence. Even if we could make a computer program that was as intelligent as a person (and would therefore pass the Turing test), it would still be distinguishable from a human.
They are not at all necessary but they are some ways in which you can distinguish a human being from a chatbot.
To be fair, the grandparent post probably meant 'if all you can do is interact by typing text into a computer and reading replies, then a sufficiently advanced chatbot is indistinguishable from a human'. Then again, given that definition, I can easily write a chatbot that is indistinguishable from an illiterate human.
My point is that there is more to social interaction than exchanging strings of text.
On the other hand, the tech industry is full of crusty legacy systems and protocols which were never that great to start with but it would be too much effort to change now. There are good trusty old workhorses - but there is plenty of old crap too.
Often you get the worst of both worlds. New versions of Windows have dubious new features to justify upgrading, but still lug along all the nasty DOS / Win16 / Win32 APIs as well for backwards compatibility.
In some ways that is a big advantage, if you want to automate filesystem-ish operations like traversing directories, creating new files with a given name, listing them and so on. There is no standard way to do this over http, except for the convention that the URI includes the filesystem path. But if you are just setting up a download site and not allowing uploads from the public (the common case?) then an Apache directory listing does the job fine.
Well, since no version of Windows I know of comes with SSH/SCP/SFTP support out of the box, I think you have your reason right there.
But even if you have Windows clients, still, why would you try to use ftp for authenticated transfers? It is sending the password in plain text where anyone can sniff it, and there is no protection against someone reading or modifying the data in transit. If your data is not sensitive then just allow anonymous access. Windows may not include an sftp client but it does come with Internet Explorer which is capable of doing https and securely sending a username/password to authenticate. Again, is there any reason to use ftp?
The only situation I can think of is where you want to restrict access but you don't really care about security. For example only paying customers have access to the FTP site, but the data you publish is essentially non-secret. Then you could require a username and password to connect, even though you know it won't stop a determined attacker sniffing the network traffic. But even in this situation http or https with username/password authentication could do the job just as well.
Not to belittle your cause at all, but who still uses floppies any more?
I just picked up a 2.4Ghz Xeon workstation that my office was throwing out. It still works but the CD player has been removed for use in another machine. I want to put Fedora on it.
Slashdot Mirror
Indeed, on the face of it the proposal reminds me of range voting. If only each user would voluntarily agree to take less bandwidth than they're able to get, then the net would run more smoothly. But no P2Per would install the upgrade from Microsoft or from his Linux distribution to replace the fast, greedy TCP stack with a more ethical, caring-sharing one that makes his downloads slower.
What I don't understand is why this concerns TCP at all. An ISP's job is surely to send and receive IP datagrams on behalf of its customers. What you do in the higher levels of the protocol stack is up to you; some apps may be using UDP, others SCTP or other TCP replacements. The backoff and error correction of TCP is intended to ensure reliable connections between one host and another, not to somehow manage congestion for the whole Internet. Back in the days when the net was only thirty thousand hosts big and everyone had a competent, public-spirited sysadmin it used to work to insist that everyone change their client software for the greater good. Not now.
If any congestion filtering needs to be applied it should be done at the level of IP datagrams, no matter what they contain. If clients feel that high-priority applications like web browsing or VoIP shouldn't be blocked by P2P traffic, then they can set the priority field accordingly. Of course, this would instantly be defeated if ISPs honour that field too naively; everyone would just set all traffic to the highest priority level. An ISP would have to weight the priorities of a given subscriber based on their historical average, so that someone who sends every packet marked TOP URGENT gets no benefit.
Congestion notification is surely useful, as an additional mechanism to help higher levels of the network stack respond to packets being dropped or delayed lower down. But you can't rely upon users to always honour these voluntary systems. Any mechanism that is voluntary and isn't linked to some kind of metering or charging will be subverted, and probably sooner than you think. So the EFF and others are entirely right to suggest ISPs use metering. As long as the terms of service are clearly defined and you get what you pay for (so no bogus 'unlimited' promises), I don't see anything wrong in that.
What a storm in a teacup. Will anyone except Microsoft shops want to run Microsoft's virtualization product? Will they care that Debian isn't a 'supported platform', whatever that means? It's not as if other Linux versions won't run; just you won't be able to get Microsoft's famously good technical support to help with setting them up.
Hmm, that seems wasteful somehow; can't they both just agree on a single Lisp dialect and use two instances of the the same interpreter?
Database systems use that sort of thing all the time, telling the kernel not to bother caching their file I/O but send it straight to disk (of course, they have their own cache configured by the database administrator). Typically if it needs to scan table more than the size of available memory, it reads the data from start to finish off the disk but doesn't cache any of it.
My BBC had BASIC 1.0 and it supports named procedures fine. It lacks EQUB and similar assembler directives, which makes it a pain to include literal byte values or strings in your assembly language programs. These were added in BASIC 2.0.
+1
It is not a security flaw to store passwords in plain text - or at least, 'encrypting' them with some fixed algorithm gives no security benefit. At best it's security through obscurity.
In fact, it's surprisingly sensible of Microsoft to recognize this, given the 'compressible encryption' and other non-security security nonsense they provide in other products.
You're talking about Adaptive Server Anywhere (ASA) but the one that shares a lineage with MSSQL is Adaptive Server Enterprise (ASE). They are different products with different codebases.
But you have a point that many people, yourself included, are stuck with Windows. It wouldn't be easy to migrate. Much more convenient to buy some crappy virus scanner and keep the plates spinning.
If you think that's too slow, then the validation could be done asynchronously and if a script starts generating invalid pages then it could be temporarily disabled while the administrator investigates.
YYYY-MM-DD would be better; the different delimiter character avoids confusion with other date formats. This is the standard date and time notation.
'course, if you're making subdirectories on a Unix filesystem, using / is handy.
Surely 22/7 would be pi day.
Yes - an intelligent being doesn't have to be able to eat cornflakes; somehow I misread with s/intelligent/human/. Sorry.
Thanks for the correction, you are quite right.
Of course a sufficiently advanced chatbot would be intelligent.
Ah... and I see I'm being a muppet here, because the original statement said 'an intelligent being'. Apologies to all.
I didn't mention intelligence.
I was referring to the original statement 'any sufficiently advanced chatbot is indistinguishable from a human'. But there are many more features of human beings than just their intelligence. Even if we could make a computer program that was as intelligent as a person (and would therefore pass the Turing test), it would still be distinguishable from a human.
They are not at all necessary but they are some ways in which you can distinguish a human being from a chatbot.
To be fair, the grandparent post probably meant 'if all you can do is interact by typing text into a computer and reading replies, then a sufficiently advanced chatbot is indistinguishable from a human'. Then again, given that definition, I can easily write a chatbot that is indistinguishable from an illiterate human.
My point is that there is more to social interaction than exchanging strings of text.
Of course that's not true, because a chatbot cannot eat cornflakes, ride a horse or have children.
On the other hand, the tech industry is full of crusty legacy systems and protocols which were never that great to start with but it would be too much effort to change now. There are good trusty old workhorses - but there is plenty of old crap too.
Often you get the worst of both worlds. New versions of Windows have dubious new features to justify upgrading, but still lug along all the nasty DOS / Win16 / Win32 APIs as well for backwards compatibility.
It's quite possible in principle to set up an sftp server authenticating against LDAP or what have you.
In some ways that is a big advantage, if you want to automate filesystem-ish operations like traversing directories, creating new files with a given name, listing them and so on. There is no standard way to do this over http, except for the convention that the URI includes the filesystem path. But if you are just setting up a download site and not allowing uploads from the public (the common case?) then an Apache directory listing does the job fine.
The only situation I can think of is where you want to restrict access but you don't really care about security. For example only paying customers have access to the FTP site, but the data you publish is essentially non-secret. Then you could require a username and password to connect, even though you know it won't stop a determined attacker sniffing the network traffic. But even in this situation http or https with username/password authentication could do the job just as well.