I've tried lyx. I need xemacs to be happy, though.
I don't have a problem with text markup -- I just don't like LaTeX's particular syntax. It makes a lot of characters metacharacters (which makes it a pain to past text in). A lot of characters that I think should be "regular" characters are only valid in math mode. I hate the way LaTeX deals with wrapping (I never want text going off the page, really). I hate trying to deal with cell-spanning in tables, which should really be part of the basic tabular environment -- it's easy in HTML, and a pain in LaTeX. I wish LaTeX could let me just say "I want this floating element embedded in the text as close as possible to my text without ruining the look of the document". I wish that it was easier to use LaTeX as a full-blown programming language.
I've tried other free layout systems, and never liked anything as much as LaTeX, but LaTeX is an awfully long way from perfect.
It is as long as clients download from other clients indiscriminately, which is what the majority, if not all, do. HTTP already provides caching - and it's caching that works well, as you almost always get resources from a computer that is closer to you on the network. Typical P2P clients retrive resources from all over the place, leading to not only slower downloads, but unnecessary transfers.
I guess it comes down to what you define as "smart caching".
It certainly caches, the question is whether it's considered to be smart or not. I guess you do not.
It is actually HTTP. Not "like" HTTP. HTTP.
Try sending "GET/" to your favorite Gnutella client, and see whether you get "file not found" or "syntax not understood".
HTML 4.01 already provides this. Look into the <link> element type.
I'm aware of this; this is currently provided in browsers by overloading existing controls instead of adding new "recommended navigation" controls.
No ASCII armoring of digital signatures required, that can be handled in a standard way by XML signature.
I don't know why there's any reason to armor signatures at all, frankly, outside of archaic mail clients -- the modern format is to slap the signature in as an attachment, which means that it'd be just as easy to base64-encode the attached signature as it would a.gif that's being sent.
I mean, there *is* some parsing code involved, and theoretically one could rework headers and whatnot to be in XML, but there is huge amounts of deployed software that uses the existing parsing code, and it's not as if an XML-based storage of them would be significantly better in any way that I can see. If anything, I view base64 encoding as more regular than that encoding XML does (IIRC, "With all due respect, I disagree. The basic mechanisms in use today don't vary much at all, but cookies are a kludge with all sorts of special cases. Netscape's original design was decent for its time, but hasn't been significantly improved upon since its introduction.
Okay, I guess I should say... what issues do you have with cookies being used to store state?
I disagree. Where are the HTTP clients that can't store a few KB in memory during a website visit?
Embedded devices. Sure, each one isn't expensive -- you're talking maybe a few cents of additional cost to add some more onboard RAM -- but it is per-unit, which sucks.
I get very, very few software packages not in RPM format -- most useful packages are packaged these days. Most of the stuff I use that isn't in RPM format are perl scripts that people have written.
God, I love Slashdot. There really isn't anywhere else in the world quite like it.
[getting back to the point]
A friend of mine just put together a TB server (using a mix of PATA, SATA, and SCSI, apparently for the hell of it:-) ) The box runs Linux, and his SATA controller (SiI3112) has been a bit flaky -- I dunno if this is common or just for whoever manufactured the thing, but it's been enough to make me want to hold off SATA for a while, until Linux drivers mature a bit.
Seagate now has a nice 5 year warranty, which match well with good quality and reasonably cheap drives. Look at some of the SATA drives like the Barracuda.
I dunno about the SATA bit. SATA is new, and I've seen quirkiness with Linux and SATA controllers thus far. I think it might be safer to let other people hit all the issues first, and let the drivers be solidified.
How are the licenses for PGP and GPG? I have to wonder why web mail environments haven't tried stuff like this. You could completely hide all the complexity within the service and between known PGP/GPG-happy services.
The problem is that the trust system bundled with GPG (not that you couldn't build something on top of GPG's trust system) is binary -- you trust someone or you don't. There's no concept of "sorta trusting persona A, and therefore trusting persona B, which persona A trusts, somewhat less".
SSL would be a fine example then, it's a trivial requirement of pretty much everybody who is setting up a webserver, even if they aren't going to buy a cert pretty much everybody needs ssl for something.
Somehow, I managed to cut out what I was typing. I was trying to write that back in the day, almost nobody bundled SSL, so there were few people using it, which was almost certainly a factor in good tutorials not being around.
99% of the time windows applications don't fail to install in the form they are distributed. 3rd parties can achieve this rate with linux, but the project site distributes source that fails to compile simply by following the./configure make make install that is usually the only installation instruction.
Oh, surely not quite yet. The ISO committes are good at being certain not to avoid including anything that someone might want, but they aren't perfect, and we need to be sure to avoid missing crucial features.
Actually, to further ADA compliance, it should be full video (with captioning), that way not only do the blind get access, but the deaf as well.
This is a good example. We were ready to go to ISO with this. But there are more -- what about dual-language law in states bordering Mexico? We should also include Spanish subtitles. And to only include Spanish and English would not fully serve the needs of, for example, Swahili speakers -- surely they deserve their own subtitles.
Consider the problem of dealing with revisions -- only a few file formats allow revision-tracking. Clearly, we should not exclude such a useful feature. Each file should also contain deltas from all previous revisions of that file -- much like a file in a CVS repository.
Use of such a mechanism is not compliant with the Americans with Disabilities Act. The proper, legal approach is to embed WAVE files of the text being read, and verbal descriptions of all graphics.
Furthermore, citation is a significant problem on the Internet (for example, used resources can go away if cited by URLs). We need to solve the citation problem -- the appropriate approach is to embed all files used as sources of content for the existing file (which would, in turn, contain copies of all *their* sources, etc).
I love the concept behind LaTeX. I love the quality of the output from existing LaTeX implementations.
That being said, the syntax of LaTeX is a pain to learn, a pain to code in, and just not all that great.
Now, I deal with the syntax because the approach of higher-level formatting is so good, and because the implementation is so good, but boy I wish that it was better.
Oh, and LaTeX doesn't have the excellent error detection and reporting of, say, perl.
This will never happen unless systems like cacert.org start to take off.
Or decentralized trust systems, but yes.
Basically 99% of the internet don't give a damn about certificates, and the ability for anonymity is more limited.
Not really. I can create multiple electronic personas, unless you're trying to enforce a 1:1 id:person ratio.
2. SPF-like protocols - This is the ability to discriminate who is and who isn't allowed to send email from a given domain. This will cause a few things:
Where "SPF-like protocols" means "authorization protocols", yes. The problem is really nothing more than an authorization protocol, and not a very good one at that.
I disagree with you that authorization should take place on a domain level (unfortunately, this is the approach that the SPF people use). By doing so, it means that, say, a single account at ford.com is ever compromised by a baddie, it means that the only solution with domain-level granularity systems is to ban the entire domain.
If all those things in the title were used to develop a website, i think the things one could accomplish are amazing. as it stands you can already use xhtml and xhmlhttprequest to do highly dynamic websites.
"highly dynamic websites". Hmm. What specifically do you mean by this?
i wish browsers could automatically detect what version of html the webpage requires, and generate warnings if your browser's too old to properly render, with a handy "update here" link.
Browsers and website designers already have the ability to do this. The reason they don't is that it's a pain in the ass for the user.
Almost all existing P2P filesharing-oriented servents reshare downloaded files. From that standpoint, the statement is not unreasonable.
And many common implementations actually use HTTP.
Not that I'm aware of. Gnutella uses an HTTP-like protocol, which is as close as I can think of.
Sure. I'd refactor XHTML to include more useful element types (e.g. ).
I disagree. The current behavior of navigation controls operates on a meta-level -- the operator never gets control over what they do. In the past, giving website designers over control of web browser controls has widely resulted in poor decisions being made -- IE has taken a "web designer has control" approach, Mozilla a "user has control". Plus, it only takes a small percentage of poor usage or abuse of controls ("back" keeping people on the same ad, for instance) to make a control not worth it.
I could see a *new* set of interface controls "recommended-back", "recommended-forward", "recommended-up", "recommended-help", etc being introduced, but not overloading the existing controls.
I'd switch protocols like SMTP and formats like RFC2822 over to Unicode/XML.
Why do you dislike the existing MIME-encoded method of handling Unicode data?
What would be the benefit of XML usage?
I'd make maintaining state something intrinsic to HTTP.
Why? Demands for state maintenance vary widely across HTTP-using systems -- web browsers can be pigeonholed, sure, but cookies are already there and work nicely. What if you need five megs of state (different mechanism from cookies), or need to have the client aware of the content of the state? There are a lot of systems that can't afford to maintain state, like embedded systems.
But first of all, I'd beat people who use buzzwords without understanding what they mean with one gigantic, fuck-off-big cluestick.
I really don't think that he was all that awful, really.
You know exactly what he meant, and simply couldn't pass up the opportunity to bash him to demonstrate your maximum geekiness.
Please study TCP/IP better before you ask such a question again.
You know what I've found? Professors and people that generally understand a subject are generally not assholes towards people that make an error in it (maybe if they're frusterated) -- they try to correct errors. It's the kind of people that just got their MSCE who feel the need to demonstrate how badass they are by insulting others.
The question was not unreasonably formatted. The most-frequently used application-level protocol on the Internet is HTTP. The only other protocol directly used much by almost all Internet users are the mail-related protocols. The main way that people retrieve data and interact with servers on the 'Net is HTTP. Often, the HTTP-associated well-known ports 80 and 443 are the only non-firewalled outbound ports allowed to Internet-connected desktop machines. You're using a Web browser to read this at the moment. Other protocols are increasingly tunneled over HTTP. Saying that we have an "HTTP Internet" is entirely reasonable.
First, I would re-design IP to take variable-length addresses, so IPv4, IPv6 and everything else to come are all compatible and interchangable.
As I go into detail in in my post futher in this thread, I don't think that this is a good idea. It makes optimizations harder, and IPv6 should never need to be extended as long as it is properly used. Furthermore, unless a new protocol uses the *exact same* routing mechanisms and *only* changes address length, compatibility gets broken anyway. I think the gain may not be what you're hoping for -- you couldn't just slap IPX on an IP network, for example.
I do think that the fact that the BSD sockets API was designed to deal so poorly with long addresses is a real disaster, though. The *endpoints* of a connection-oriented address generally only care about the length of the address.
Then I would re-design DNS so that you have to provide not just a domain name to resolve to an IP number, but a "resource type" such as SMTP, HTTP, etc. (similar to MX records, but generic). Each resource type would have its own associated IP number and port.
SMTP/HTTP are not resource types. They are protocols.
You could have a "WWW" resource type, I guess.
This is already done, with well-known ports -- the advantage of using well-known ports is that the additional network traffic and latency is avoided.
I would unify all the protocols under a single HTTP-like protocol and make everything, FTP, SMTP, NNTP, etc. a direct extension of it.
Hmm. I dunno. I guess you could wrap these in HTTP, but where's the benefit of doing so? You can't really reuse any significant functionality and you'd slightly increase complexity (since everything would need to be linked to an HTTP library).
I would merge CGI and SMTP DATA into a single "data" mechanism that could be used with any of the protocols uniformly.
Hmm. I'm not quite sure what the benefit to doing so would be.
I would clean up the protocol so it's possible to concatenate multiple lines together without ambiguity, and uniformly, so the method for multiple line headers is the same as multiple lines of data.
Wouldn't this just impose overhead on protocols that use an eight-bit-clean and non-line-oriented interface, like FTP DATA?
I would also move SSL authentication into that protocol, rather than having it at the TCP level.
Not sure what you mean... I guess you'd make every protocol SSL-tunneled? I mean, I think it's a good idea (more plaintext services becoming encrypted == better), but you can already do that, and the main reason that people don't is because of (now archaic) patent issues and because of CPU load. Also, SSL adds overhead, not just on the CPU, but in latency.
This would make shared hosting simpler and would save us a LOT of IPv4 numbers.
I don't see why this would be the case.
I would peel the skin off of anyone who suggests that XML become an integral part of that protocol. XML is wordy, wasteful, hard to read and should be a high-level choice, not a low-level foundation.
Thank you. I've seen one utterly idiotic proposal for doing something like what you're proposing and ramming everything through XML, which is ridiculous.
XML may be the most overused and oversold format ever. It's neat for a certain set of tasks, but it has no benefit for many things that it is used for.
I see no fundamental barrier to something like this.
No, but it is easier for a chip engineer to make optimizations with constant-length addresses.
And, honestly, as long as we're using IPv6 addresses as actual addresses, as they're intended to be used, I just cannot see length being an issue again. (Problems will come up if some idiot tries ramming additional data into the thing, like a MAC address.)
*) Lots of web designers think animation is a good idea. They tend to use it more than a user would like (especially since the "is it cool" metric, where users are asked for initial impressions of a site rather than to use the thing for a month and their feelings on usability) is wildly tilted toward novelty. Animation is almost never a good idea from a usability standpoint on a website.
*) Lots of people doing Flash try to do lots of interface design, going so far as to bypass existing, well-tested and mature interface work with their own pseudo-widgets. They usually don't know what they're doing.
*) Flash is slow to render.
*) Flash is complex, and it's hard to secure the client-side Flash implementation compared to, say, a client-side HTML rendering engine.
*) The existing Flash implementation chews up as much CPU time as it can get.
*) Flash does not allow user-resizeablity of font sizes.
*) Flash does not allow for meta-level control over some things, like "music playing in the background". Some websites provide a button for this. I don't want to have control if the designer choose to give me control -- I never want that software playing music if I choose to not have it do so.
*) Flash does not allow user-configurable font colors (and for some reason, too many Flash designers seem to think that "ten-pixel high light blue text on dark blue looks great to them, so everyone should also be able to read their site as easily).
*) Because Flash maintains internal state that is not exposed via URL, it's not possible to link to a particular state of a Flash program -- this means that you can only link to a Flash program, not a particular section of one. This is very annoying -- I can link to any webpage on a site, but sites that are simply one Flash program disallow deep linking. (I'm sure that concept gets a number of designers up somewhere near orgasm, but it drives users bananas.)
*) The existing Flash implementation is not nearly as stable as the other code in my web browser, and takes down the web browser when it goes down.
*) As you pointed out, I can't search for a "page" in a Flash program.
Really, the main benefit of avoiding Flash to me is that it keeps web designers from doing a lot of things that seem appealing to them but are actually Really Bad Ideas from a user standpoint. Almost without exception, Flash has made sites I've used worse (the only positive example I can think of was either a Javascript or Flash in which the manufacturer of a hardware MP3 player demoed their interface to website users).
I *have* seen Flash used effectively as a "vector data movie format", for which it is an admirable format -- I suspect most Slashdotters have seen the Strong Bad cartoons at some point or another. But I simply do not like it as an HTML replacement.
Personally I want a protocal to replace IP. I want verified connection lists, basically a firewall built into the protocal, to only allow verified connections and warn on others.
IPSec? At the application level, SSL?
I want IP privacy masking, meaning If I connect to a server, it won't record my IP, and my IP will never be seen on the public network. The phone company can "block caller ID" Why can't an ISP block "host IP?"
Oh, it can. Lots of ISPs provide web proxies, in particular (they'd probably be tickled pink if people would regularly use proxies, and save them bandwidth costs). However, it makes it even easier for the ISP to track you. The majority of people I've talked to interested in masking are primarily interested in not having illegal activities tracked, and if anything, it's easier for police to find out an identity by going to the ISP and asking for their logs.
There's already been a full anonymity service provided by Zero Knowledge Systems. They even provided onion-skin routing within their own network to make external traffic analysis on their network a pain in the ass. Nobody bought it -- people don't understand or want to pay for anonymity. ZKS went on to do other things.
* The primary addressing mechansim would be content-based addressing (like SHA1 hashes of the content being addressed). We have problems with giving reliable references for things like bibliographies. We are gradually moving in this direction. P2P networks are now largely content-addressed, and bitzi.com provides one of the early centralized databases for content-based addressing.
* We would have a global trust mechanism, where people can evaluate things and based on how well other people trust their evaluations, those people can take advantage of their evaluations. Right now, web sites have very minimal trust mechanisms (lifetime of domain, short domain names, and the generally-ignored x.509 certs). This would apply not just to domains, but be more finely-grained and apply to content beneath it.
* The concept of creatable personas would exist. Possibly data privacy laws would end up requiring companies not to associate personas, or perhaps we would just make it extremely difficult to associate such personas. You would maintain different personas which may, if so desired, be separate. Such personas would be persistent, and could be used to evaluate how trustworthy people are -- e.g. if Mr. Torvalds joins a coding forum and makes some comments about OS design, he can simply and securely export his persona (a pubkey and some other data) from the other locations that he has been using that persona (like LKML, etc) and benefit from the reputation that has accrued to that persona. This would eliminate impersonation "this is the *real* Linus Torvalds website", etc.
* Such trustable, persistent personas would allow for the creation of systems to allow persistent contact information to be provided ('snot that hard). This means no more dead "email addresses".
* Domain names not be used as the primary interface mechanism to users for finding and identifying data providers. This is halfway handled already -- most people Google for things like "black sabbath" instead of looking for the official Black Sabbath website by typing out a single term. It's still possible for people to "choose their visual appearance", though, and Visa looks very much like "visa-checking.com", as long as end users have control over how domains are presented to users.
* P2P becomes a primary transport mechanism for data -- from an economic standpoint, this means that consumers of data are responsible for subsidizing continued distribution of that content, and shifts the burden from the publisher of the content -- one step removed from consumers funding the production of their content. It solves many of the economic issues associated with data distribution. For this to happen, P2P protocols will have to be strongly abuse-resistant, even if that means a lesser degree of performance or efficiency. Many existing systems have severe flaws -- Kazaa, for instance, allows corrupted data to be spread to users, and conventional eDonkey (sans eMule extensions) does not provide any mechanism to avoid leeching, which destroys the economic benefits. Sadly, one of the few serious attempts to address the stability of the system was also from Bram Cohen of BitTorrent and abandoned -- called Mojo Nation, it used a free-market economic system to determine resource allocation, and was fairly abuse resistent. I have some efforts in this direction, but don't use a free-market model.
* Email and instant messaging will merge to a good degree (or perhaps one will largely "take over"). Up until now, it has mostly been techncial limitations in existing software that has kept one from supplanting the others -- email provides poor delivery-time guarantees, instant messaging provides message size limitations. Email uses a strictly thread-based model, instant messaging uses a strictly linear model. Probably someone will coin a new, stupid term for the mix of the twain (like "instant mail").
* Personas and global trust networks (not extremely limiting binary-style trust, a la PGP/GPG), as mention
mysql (almost all the documentation is wrong, and I mean the simplest stuff is wrong, like working with authentication). They have lots of documentation, but most of it is inaccurate, out of date, and in many cases was ALWAYS wrong. They rely too much on the ability of users to comment on given pages of documentation. But those users are wrong half the time, and even when they are right their contributions don't seem to ever be added.
I confess that I've never seriously used mysql. I was impressed with the presentation of their docs, but they certainly could be wrong, and I wouldn't know.
Apache, dear god just look at it. Their documentation is basically a quick reference, they list all kinds of options and generally out of context. Have these people never heard of tutorials?
I've never had a problem with Apache's documentation. The only time I've looked for a tutorial-style document and been dissatisfied was when I was trying to set up SSL (this is back when many distros,
I've yet to find a ftp server with good docs either, again the same problem. In the case of ftp servers they seem to have an obsession with large anonymous ftp (aside from universities and large software vendors who actually wants to do this?).including Red Hat, didn't ship SSL support, so very few people could it).
I use vsftpd -- I admit that it isn't a very complicated ftpd, but it's certainly not hard to find what you're looking for.
Remember that, until the Web got big, anonymous ftp was simply how you distributed *everything*.
If any other option they give the ability to have users log into their system accounts home directory, talk about a pain in the arse to manage and keep seperate from other services. I suppose if you were doing web hosting this is what you'd want, but not for anything else.
True enough, but this isn't really a documentation issue -- it's just a legacy of how *IX systems are generally used.
Most things assume that actually using the software is obvious, or the other way, they assume you've had no problem installing.
I dunno. When was the last time that you had a set of good documents on what to do if your closed-source Windows applications failed to install?
I'd say that in general (even aside from documentatin), software doesn't deal too well with failure to install. You generally have to have a pretty good idea of what you're doing to fix a failure to install.
COMPLETE Documentation is needed, that covers everyone from complete novice and idiot who nothing nothing about the app or the OS to power users who know nothing about the app. Even advanced documentation should be written from the perspective that the user knows nothing about the app.
If you've never heard of Mathematica or MATLAB or Photoshop or any other kind of serious closed-source software, you're not going to pick things up by just skimming over the documentation -- you're going to have to maybe read a book or take a class, or read things written by other people and spend a lot of time coming up to speed on it. I'm not saying that "more documentation != good", I'm just saying that I think you're expecting more from open-source software than I've ever seen closed-source packages do. Heck, most closed-source packages don't even ship with good manuals any more -- the last time I got a nice multi-hundred-page manual with a package with tutorials and feature-by-feature descriptions was *SuperPaint* for the Mac, years ago.
The docs should also always apply to the latest stable version, if the docs havent been checked and updated, then the new version isn't stable yet. The docs should be considered part of the release
The docs should also always apply to the latest stable version, if the docs havent been checked and updated, then the new version isn't stable yet. The docs should be considered part of the release.
Here I'll agree, but I've also seen plenty of times that closed-source software will ship documentation for the last major version with some "updates" information. It's not that unusual.
I dunno. Maybe you've just used some closed-source software packages with particularly good documentation that I've never been fortunate enough to use.
do you really trust the Microsoft encryption to do anything else than making your systems slower?
I'm not sure that I'd want to directly trust either the Windows or the Linux code with my life WRT the presence of zero flaws.
On the other hand, I'd rely on both of them to be pretty solid, and be comfortable using either for data encryption of sensitive, classified, or incriminating data.
You just found the point where they will breach your data security.
It's still something that a lot of organizations will want to have before they deploy something. The IT guy is nearly always a security hole anyway -- he's setting up the computer and saying "you can trust this". You might as well trust him with recovery duties as well.
Slashdot Mirror
I've tried lyx. I need xemacs to be happy, though.
I don't have a problem with text markup -- I just don't like LaTeX's particular syntax. It makes a lot of characters metacharacters (which makes it a pain to past text in). A lot of characters that I think should be "regular" characters are only valid in math mode. I hate the way LaTeX deals with wrapping (I never want text going off the page, really). I hate trying to deal with cell-spanning in tables, which should really be part of the basic tabular environment -- it's easy in HTML, and a pain in LaTeX. I wish LaTeX could let me just say "I want this floating element embedded in the text as close as possible to my text without ruining the look of the document". I wish that it was easier to use LaTeX as a full-blown programming language.
I've tried other free layout systems, and never liked anything as much as LaTeX, but LaTeX is an awfully long way from perfect.
It is as long as clients download from other clients indiscriminately, which is what the majority, if not all, do. HTTP already provides caching - and it's caching that works well, as you almost always get resources from a computer that is closer to you on the network. Typical P2P clients retrive resources from all over the place, leading to not only slower downloads, but unnecessary transfers.
/" to your favorite Gnutella client, and see whether you get "file not found" or "syntax not understood".
.gif that's being sent.
... what issues do you have with cookies being used to store state?
I guess it comes down to what you define as "smart caching".
It certainly caches, the question is whether it's considered to be smart or not. I guess you do not.
It is actually HTTP. Not "like" HTTP. HTTP.
Try sending "GET
HTML 4.01 already provides this. Look into the <link> element type.
I'm aware of this; this is currently provided in browsers by overloading existing controls instead of adding new "recommended navigation" controls.
No ASCII armoring of digital signatures required, that can be handled in a standard way by XML signature.
I don't know why there's any reason to armor signatures at all, frankly, outside of archaic mail clients -- the modern format is to slap the signature in as an attachment, which means that it'd be just as easy to base64-encode the attached signature as it would a
I mean, there *is* some parsing code involved, and theoretically one could rework headers and whatnot to be in XML, but there is huge amounts of deployed software that uses the existing parsing code, and it's not as if an XML-based storage of them would be significantly better in any way that I can see. If anything, I view base64 encoding as more regular than that encoding XML does (IIRC, "With all due respect, I disagree. The basic mechanisms in use today don't vary much at all, but cookies are a kludge with all sorts of special cases. Netscape's original design was decent for its time, but hasn't been significantly improved upon since its introduction.
Okay, I guess I should say
I disagree. Where are the HTTP clients that can't store a few KB in memory during a website visit?
Embedded devices. Sure, each one isn't expensive -- you're talking maybe a few cents of additional cost to add some more onboard RAM -- but it is per-unit, which sucks.
I get very, very few software packages not in RPM format -- most useful packages are packaged these days. Most of the stuff I use that isn't in RPM format are perl scripts that people have written.
That should really be "doubleclick". "Doubleclock" is presumably an innocent company that has never served up an ad in their life.
Would a cracker 127.0.0.1'ing doubleclock via a worm or virus be a black hat or a white hat?
Buy web hosting from a girl geek! [simpli.biz]
:-) ) The box runs Linux, and his SATA controller (SiI3112) has been a bit flaky -- I dunno if this is common or just for whoever manufactured the thing, but it's been enough to make me want to hold off SATA for a while, until Linux drivers mature a bit.
God, I love Slashdot. There really isn't anywhere else in the world quite like it.
[getting back to the point]
A friend of mine just put together a TB server (using a mix of PATA, SATA, and SCSI, apparently for the hell of it
Seagate now has a nice 5 year warranty, which match well with good quality and reasonably cheap drives. Look at some of the SATA drives like the Barracuda.
I dunno about the SATA bit. SATA is new, and I've seen quirkiness with Linux and SATA controllers thus far. I think it might be safer to let other people hit all the issues first, and let the drivers be solidified.
How are the licenses for PGP and GPG? I have to wonder why web mail environments haven't tried stuff like this. You could completely hide all the complexity within the service and between known PGP/GPG-happy services.
The problem is that the trust system bundled with GPG (not that you couldn't build something on top of GPG's trust system) is binary -- you trust someone or you don't. There's no concept of "sorta trusting persona A, and therefore trusting persona B, which persona A trusts, somewhat less".
SSL would be a fine example then, it's a trivial requirement of pretty much everybody who is setting up a webserver, even if they aren't going to buy a cert pretty much everybody needs ssl for something.
./configure make make install that is usually the only installation instruction.
Somehow, I managed to cut out what I was typing. I was trying to write that back in the day, almost nobody bundled SSL, so there were few people using it, which was almost certainly a factor in good tutorials not being around.
99% of the time windows applications don't fail to install in the form they are distributed. 3rd parties can achieve this rate with linux, but the project site distributes source that fails to compile simply by following the
RPMs?
Time to apply for ISO?
Oh, surely not quite yet. The ISO committes are good at being certain not to avoid including anything that someone might want, but they aren't perfect, and we need to be sure to avoid missing crucial features.
Actually, to further ADA compliance, it should be full video (with captioning), that way not only do the blind get access, but the deaf as well.
This is a good example. We were ready to go to ISO with this. But there are more -- what about dual-language law in states bordering Mexico? We should also include Spanish subtitles. And to only include Spanish and English would not fully serve the needs of, for example, Swahili speakers -- surely they deserve their own subtitles.
Consider the problem of dealing with revisions -- only a few file formats allow revision-tracking. Clearly, we should not exclude such a useful feature. Each file should also contain deltas from all previous revisions of that file -- much like a file in a CVS repository.
That is correct. In spite of the similar names, they have almost nothing to do with each other, beyond the fact that html is often delivered via http.
What you are saying is not contrary to what the article author said in the first place.
Use of such a mechanism is not compliant with the Americans with Disabilities Act. The proper, legal approach is to embed WAVE files of the text being read, and verbal descriptions of all graphics.
Furthermore, citation is a significant problem on the Internet (for example, used resources can go away if cited by URLs). We need to solve the citation problem -- the appropriate approach is to embed all files used as sources of content for the existing file (which would, in turn, contain copies of all *their* sources, etc).
I love the concept behind LaTeX. I love the quality of the output from existing LaTeX implementations.
That being said, the syntax of LaTeX is a pain to learn, a pain to code in, and just not all that great.
Now, I deal with the syntax because the approach of higher-level formatting is so good, and because the implementation is so good, but boy I wish that it was better.
Oh, and LaTeX doesn't have the excellent error detection and reporting of, say, perl.
This will never happen unless systems like cacert.org start to take off.
Or decentralized trust systems, but yes.
Basically 99% of the internet don't give a damn about certificates, and the ability for anonymity is more limited.
Not really. I can create multiple electronic personas, unless you're trying to enforce a 1:1 id:person ratio.
2. SPF-like protocols - This is the ability to discriminate who is and who isn't allowed to send email from a given domain. This will cause a few things:
Where "SPF-like protocols" means "authorization protocols", yes. The problem is really nothing more than an authorization protocol, and not a very good one at that.
I disagree with you that authorization should take place on a domain level (unfortunately, this is the approach that the SPF people use). By doing so, it means that, say, a single account at ford.com is ever compromised by a baddie, it means that the only solution with domain-level granularity systems is to ban the entire domain.
If all those things in the title were used to develop a website, i think the things one could accomplish are amazing. as it stands you can already use xhtml and xhmlhttprequest to do highly dynamic websites.
"highly dynamic websites". Hmm. What specifically do you mean by this?
i wish browsers could automatically detect what version of html the webpage requires, and generate warnings if your browser's too old to properly render, with a handy "update here" link.
Browsers and website designers already have the ability to do this. The reason they don't is that it's a pain in the ass for the user.
"P2P" isn't smart caching.
Almost all existing P2P filesharing-oriented servents reshare downloaded files. From that standpoint, the statement is not unreasonable.
And many common implementations actually use HTTP.
Not that I'm aware of. Gnutella uses an HTTP-like protocol, which is as close as I can think of.
Sure. I'd refactor XHTML to include more useful element types (e.g. ).
I disagree. The current behavior of navigation controls operates on a meta-level -- the operator never gets control over what they do. In the past, giving website designers over control of web browser controls has widely resulted in poor decisions being made -- IE has taken a "web designer has control" approach, Mozilla a "user has control". Plus, it only takes a small percentage of poor usage or abuse of controls ("back" keeping people on the same ad, for instance) to make a control not worth it.
I could see a *new* set of interface controls "recommended-back", "recommended-forward", "recommended-up", "recommended-help", etc being introduced, but not overloading the existing controls.
I'd switch protocols like SMTP and formats like RFC2822 over to Unicode/XML.
Why do you dislike the existing MIME-encoded method of handling Unicode data?
What would be the benefit of XML usage?
I'd make maintaining state something intrinsic to HTTP.
Why? Demands for state maintenance vary widely across HTTP-using systems -- web browsers can be pigeonholed, sure, but cookies are already there and work nicely. What if you need five megs of state (different mechanism from cookies), or need to have the client aware of the content of the state? There are a lot of systems that can't afford to maintain state, like embedded systems.
But first of all, I'd beat people who use buzzwords without understanding what they mean with one gigantic, fuck-off-big cluestick.
I really don't think that he was all that awful, really.
You know exactly what he meant, and simply couldn't pass up the opportunity to bash him to demonstrate your maximum geekiness.
Please study TCP/IP better before you ask such a question again.
You know what I've found? Professors and people that generally understand a subject are generally not assholes towards people that make an error in it (maybe if they're frusterated) -- they try to correct errors. It's the kind of people that just got their MSCE who feel the need to demonstrate how badass they are by insulting others.
The question was not unreasonably formatted. The most-frequently used application-level protocol on the Internet is HTTP. The only other protocol directly used much by almost all Internet users are the mail-related protocols. The main way that people retrieve data and interact with servers on the 'Net is HTTP. Often, the HTTP-associated well-known ports 80 and 443 are the only non-firewalled outbound ports allowed to Internet-connected desktop machines. You're using a Web browser to read this at the moment. Other protocols are increasingly tunneled over HTTP. Saying that we have an "HTTP Internet" is entirely reasonable.
First, I would re-design IP to take variable-length addresses, so IPv4, IPv6 and everything else to come are all compatible and interchangable.
... I guess you'd make every protocol SSL-tunneled? I mean, I think it's a good idea (more plaintext services becoming encrypted == better), but you can already do that, and the main reason that people don't is because of (now archaic) patent issues and because of CPU load. Also, SSL adds overhead, not just on the CPU, but in latency.
As I go into detail in in my post futher in this thread, I don't think that this is a good idea. It makes optimizations harder, and IPv6 should never need to be extended as long as it is properly used. Furthermore, unless a new protocol uses the *exact same* routing mechanisms and *only* changes address length, compatibility gets broken anyway. I think the gain may not be what you're hoping for -- you couldn't just slap IPX on an IP network, for example.
I do think that the fact that the BSD sockets API was designed to deal so poorly with long addresses is a real disaster, though. The *endpoints* of a connection-oriented address generally only care about the length of the address.
Then I would re-design DNS so that you have to provide not just a domain name to resolve to an IP number, but a "resource type" such as SMTP, HTTP, etc. (similar to MX records, but generic). Each resource type would have its own associated IP number and port.
SMTP/HTTP are not resource types. They are protocols.
You could have a "WWW" resource type, I guess.
This is already done, with well-known ports -- the advantage of using well-known ports is that the additional network traffic and latency is avoided.
I would unify all the protocols under a single HTTP-like protocol and make everything, FTP, SMTP, NNTP, etc. a direct extension of it.
Hmm. I dunno. I guess you could wrap these in HTTP, but where's the benefit of doing so? You can't really reuse any significant functionality and you'd slightly increase complexity (since everything would need to be linked to an HTTP library).
I would merge CGI and SMTP DATA into a single "data" mechanism that could be used with any of the protocols uniformly.
Hmm. I'm not quite sure what the benefit to doing so would be.
I would clean up the protocol so it's possible to concatenate multiple lines together without ambiguity, and uniformly, so the method for multiple line headers is the same as multiple lines of data.
Wouldn't this just impose overhead on protocols that use an eight-bit-clean and non-line-oriented interface, like FTP DATA?
I would also move SSL authentication into that protocol, rather than having it at the TCP level.
Not sure what you mean
This would make shared hosting simpler and would save us a LOT of IPv4 numbers.
I don't see why this would be the case.
I would peel the skin off of anyone who suggests that XML become an integral part of that protocol. XML is wordy, wasteful, hard to read and should be a high-level choice, not a low-level foundation.
Thank you. I've seen one utterly idiotic proposal for doing something like what you're proposing and ramming everything through XML, which is ridiculous.
XML may be the most overused and oversold format ever. It's neat for a certain set of tasks, but it has no benefit for many things that it is used for.
I see no fundamental barrier to something like this.
No, but it is easier for a chip engineer to make optimizations with constant-length addresses.
And, honestly, as long as we're using IPv6 addresses as actual addresses, as they're intended to be used, I just cannot see length being an issue again. (Problems will come up if some idiot tries ramming additional data into the thing, like a MAC address.)
I really hate Flash.
I hate Flash for a lot of reasons.
*) Lots of web designers think animation is a good idea. They tend to use it more than a user would like (especially since the "is it cool" metric, where users are asked for initial impressions of a site rather than to use the thing for a month and their feelings on usability) is wildly tilted toward novelty. Animation is almost never a good idea from a usability standpoint on a website.
*) Lots of people doing Flash try to do lots of interface design, going so far as to bypass existing, well-tested and mature interface work with their own pseudo-widgets. They usually don't know what they're doing.
*) Flash is slow to render.
*) Flash is complex, and it's hard to secure the client-side Flash implementation compared to, say, a client-side HTML rendering engine.
*) The existing Flash implementation chews up as much CPU time as it can get.
*) Flash does not allow user-resizeablity of font sizes.
*) Flash does not allow for meta-level control over some things, like "music playing in the background". Some websites provide a button for this. I don't want to have control if the designer choose to give me control -- I never want that software playing music if I choose to not have it do so.
*) Flash does not allow user-configurable font colors (and for some reason, too many Flash designers seem to think that "ten-pixel high light blue text on dark blue looks great to them, so everyone should also be able to read their site as easily).
*) Because Flash maintains internal state that is not exposed via URL, it's not possible to link to a particular state of a Flash program -- this means that you can only link to a Flash program, not a particular section of one. This is very annoying -- I can link to any webpage on a site, but sites that are simply one Flash program disallow deep linking. (I'm sure that concept gets a number of designers up somewhere near orgasm, but it drives users bananas.)
*) The existing Flash implementation is not nearly as stable as the other code in my web browser, and takes down the web browser when it goes down.
*) As you pointed out, I can't search for a "page" in a Flash program.
Really, the main benefit of avoiding Flash to me is that it keeps web designers from doing a lot of things that seem appealing to them but are actually Really Bad Ideas from a user standpoint. Almost without exception, Flash has made sites I've used worse (the only positive example I can think of was either a Javascript or Flash in which the manufacturer of a hardware MP3 player demoed their interface to website users).
I *have* seen Flash used effectively as a "vector data movie format", for which it is an admirable format -- I suspect most Slashdotters have seen the Strong Bad cartoons at some point or another. But I simply do not like it as an HTML replacement.
Personally I want a protocal to replace IP. I want verified connection lists, basically a firewall built into the protocal, to only allow verified connections and warn on others.
IPSec? At the application level, SSL?
I want IP privacy masking, meaning If I connect to a server, it won't record my IP, and my IP will never be seen on the public network. The phone company can "block caller ID" Why can't an ISP block "host IP?"
Oh, it can. Lots of ISPs provide web proxies, in particular (they'd probably be tickled pink if people would regularly use proxies, and save them bandwidth costs). However, it makes it even easier for the ISP to track you. The majority of people I've talked to interested in masking are primarily interested in not having illegal activities tracked, and if anything, it's easier for police to find out an identity by going to the ISP and asking for their logs.
There's already been a full anonymity service provided by Zero Knowledge Systems. They even provided onion-skin routing within their own network to make external traffic analysis on their network a pain in the ass. Nobody bought it -- people don't understand or want to pay for anonymity. ZKS went on to do other things.
Let's see:
* The primary addressing mechansim would be content-based addressing (like SHA1 hashes of the content being addressed). We have problems with giving reliable references for things like bibliographies. We are gradually moving in this direction. P2P networks are now largely content-addressed, and bitzi.com provides one of the early centralized databases for content-based addressing.
* We would have a global trust mechanism, where people can evaluate things and based on how well other people trust their evaluations, those people can take advantage of their evaluations. Right now, web sites have very minimal trust mechanisms (lifetime of domain, short domain names, and the generally-ignored x.509 certs). This would apply not just to domains, but be more finely-grained and apply to content beneath it.
* The concept of creatable personas would exist. Possibly data privacy laws would end up requiring companies not to associate personas, or perhaps we would just make it extremely difficult to associate such personas. You would maintain different personas which may, if so desired, be separate. Such personas would be persistent, and could be used to evaluate how trustworthy people are -- e.g. if Mr. Torvalds joins a coding forum and makes some comments about OS design, he can simply and securely export his persona (a pubkey and some other data) from the other locations that he has been using that persona (like LKML, etc) and benefit from the reputation that has accrued to that persona. This would eliminate impersonation "this is the *real* Linus Torvalds website", etc.
* Such trustable, persistent personas would allow for the creation of systems to allow persistent contact information to be provided ('snot that hard). This means no more dead "email addresses".
* Domain names not be used as the primary interface mechanism to users for finding and identifying data providers. This is halfway handled already -- most people Google for things like "black sabbath" instead of looking for the official Black Sabbath website by typing out a single term. It's still possible for people to "choose their visual appearance", though, and Visa looks very much like "visa-checking.com", as long as end users have control over how domains are presented to users.
* P2P becomes a primary transport mechanism for data -- from an economic standpoint, this means that consumers of data are responsible for subsidizing continued distribution of that content, and shifts the burden from the publisher of the content -- one step removed from consumers funding the production of their content. It solves many of the economic issues associated with data distribution. For this to happen, P2P protocols will have to be strongly abuse-resistant, even if that means a lesser degree of performance or efficiency. Many existing systems have severe flaws -- Kazaa, for instance, allows corrupted data to be spread to users, and conventional eDonkey (sans eMule extensions) does not provide any mechanism to avoid leeching, which destroys the economic benefits. Sadly, one of the few serious attempts to address the stability of the system was also from Bram Cohen of BitTorrent and abandoned -- called Mojo Nation, it used a free-market economic system to determine resource allocation, and was fairly abuse resistent. I have some efforts in this direction, but don't use a free-market model.
* Email and instant messaging will merge to a good degree (or perhaps one will largely "take over"). Up until now, it has mostly been techncial limitations in existing software that has kept one from supplanting the others -- email provides poor delivery-time guarantees, instant messaging provides message size limitations. Email uses a strictly thread-based model, instant messaging uses a strictly linear model. Probably someone will coin a new, stupid term for the mix of the twain (like "instant mail").
* Personas and global trust networks (not extremely limiting binary-style trust, a la PGP/GPG), as mention
mysql (almost all the documentation is wrong, and I mean the simplest stuff is wrong, like working with authentication). They have lots of documentation, but most of it is inaccurate, out of date, and in many cases was ALWAYS wrong. They rely too much on the ability of users to comment on given pages of documentation. But those users are wrong half the time, and even when they are right their contributions don't seem to ever be added.
I confess that I've never seriously used mysql. I was impressed with the presentation of their docs, but they certainly could be wrong, and I wouldn't know.
Apache, dear god just look at it. Their documentation is basically a quick reference, they list all kinds of options and generally out of context. Have these people never heard of tutorials?
I've never had a problem with Apache's documentation. The only time I've looked for a tutorial-style document and been dissatisfied was when I was trying to set up SSL (this is back when many distros,
I've yet to find a ftp server with good docs either, again the same problem. In the case of ftp servers they seem to have an obsession with large anonymous ftp (aside from universities and large software vendors who actually wants to do this?).including Red Hat, didn't ship SSL support, so very few people could it).
I use vsftpd -- I admit that it isn't a very complicated ftpd, but it's certainly not hard to find what you're looking for.
Remember that, until the Web got big, anonymous ftp was simply how you distributed *everything*.
If any other option they give the ability to have users log into their system accounts home directory, talk about a pain in the arse to manage and keep seperate from other services. I suppose if you were doing web hosting this is what you'd want, but not for anything else.
True enough, but this isn't really a documentation issue -- it's just a legacy of how *IX systems are generally used.
Most things assume that actually using the software is obvious, or the other way, they assume you've had no problem installing.
I dunno. When was the last time that you had a set of good documents on what to do if your closed-source Windows applications failed to install?
I'd say that in general (even aside from documentatin), software doesn't deal too well with failure to install. You generally have to have a pretty good idea of what you're doing to fix a failure to install.
COMPLETE Documentation is needed, that covers everyone from complete novice and idiot who nothing nothing about the app or the OS to power users who know nothing about the app. Even advanced documentation should be written from the perspective that the user knows nothing about the app.
If you've never heard of Mathematica or MATLAB or Photoshop or any other kind of serious closed-source software, you're not going to pick things up by just skimming over the documentation -- you're going to have to maybe read a book or take a class, or read things written by other people and spend a lot of time coming up to speed on it. I'm not saying that "more documentation != good", I'm just saying that I think you're expecting more from open-source software than I've ever seen closed-source packages do. Heck, most closed-source packages don't even ship with good manuals any more -- the last time I got a nice multi-hundred-page manual with a package with tutorials and feature-by-feature descriptions was *SuperPaint* for the Mac, years ago.
The docs should also always apply to the latest stable version, if the docs havent been checked and updated, then the new version isn't stable yet. The docs should be considered part of the release
The docs should also always apply to the latest stable version, if the docs havent been checked and updated, then the new version isn't stable yet. The docs should be considered part of the release.
Here I'll agree, but I've also seen plenty of times that closed-source software will ship documentation for the last major version with some "updates" information. It's not that unusual.
I dunno. Maybe you've just used some closed-source software packages with particularly good documentation that I've never been fortunate enough to use.
do you really trust the Microsoft encryption to do anything else than making your systems slower?
I'm not sure that I'd want to directly trust either the Windows or the Linux code with my life WRT the presence of zero flaws.
On the other hand, I'd rely on both of them to be pretty solid, and be comfortable using either for data encryption of sensitive, classified, or incriminating data.
You just found the point where they will breach your data security.
It's still something that a lot of organizations will want to have before they deploy something. The IT guy is nearly always a security hole anyway -- he's setting up the computer and saying "you can trust this". You might as well trust him with recovery duties as well.