Slashdot Mirror

The trouble is the lusers have gotten used to thinking that 'foo.com' is the proper way to type an address, when they want 'foo.com.'. The browser can try foo.com and then its going to try foo.com.{something from my domain search suffice list}..

And this neatly demonstrates how the "domain escalation" approach would work for certificates.

When the browser is provided with https://foo/uri, it will use the configured DNS suffixes to find the server and then use the same DNS suffix to confirm that the connection should be trusted. So if you have mydomain.com. and mydomain.net. as your DNS suffixes, and foo resolves in mydomain.net., then the certificate must contain foo.mydomain.net. to be accepted.

Mind you I haven't programmed the sockets API so I don't know if it's possible to _get_ the list of DNS suffixes for a computer/connection/some other object. Maybe that's the sticking point?

I have a tomcat 6 running at home and https://boo/ and https://foo/ doesn't get me to the same page although they both point to 127.0.0.1. SO I guess wikipedia is wrong then...

you would LEARN what its good for, and make money SHOWING your clients what they can do with it.

Unfortunately SP offers very little to the casual user. To that user, the only important difference from a SMB share is versions. If you don't care about them (and most people, in most businesses, don't [*]) then there SP has zero advantage to you personally.

[*] Why hardly anyone uses versions? Because that's how humans work in real life, and because it is inconvenient (and outright dangerous) to copy versions of files onto laptops, take them on a trip, change them and then try to check in. Do you think your average PHB is going to do merging? Do you think he will be stopped by "File is read-only" warning? No, he'll go ahead and do his edits, and then *you* will be called to "put it back". Versions are a problem. I can agree that if PHBs were to be taught how to use version control systems from their first day in their training then it could be better. Still we have a problem that a laptop can't deal with versions like foo.txt;23 (long live RSX-11 and VMS!). So for everyone it is safer and easier to use file names for version control, just as they would do on paper.

Outside of that little feature, SP does have a lot of other functions - which are typically beyond even understanding of a typical user. So it has calendars, tasks, announcements, personal web pages, personal links ... and who needs that? Outlook already has a calendar and tasks; personal web pages are ridiculous for 99.999% of users; so I do have one - and I haven't touched it in months. There is an announcement hanging on the server for, I think, couple of years, and nobody is caring. The UI is quite flexible, if you are into flexing UIs - but again most people couldn't care less.

So the only area where SP is of any use is file management. And does it shine there? No. The mix of Web UI and Windows Explorer UI is horrible. Some functions work in one UI and don't in another. Tables have different formats all over the site and you can't do anything about it yourself (unless you are the admin.) On our SP you couldn't even see the file type (.txt, .pdf etc.) and the icon is a blank sheet of paper, a tiny one to boot. After some haggling the admin added the file type to some tables and not to other; I'm too tired of that mess to keep complaining.

So what SP is good for? I really don't know. It doesn't seem to be much better than a file share; it's worse, actually, because hardly any app knows how to open http://foo/path/foo.pdf and that means you can't open files from the Explorer window, and if you don't do that then your files have to be opened through the browser or downloaded as a copy onto your local drive. As I said, a mess. It does have better logging, though, of who did what, so if that is seriously required then you at least can know who deleted some file (but you won't have the file unless you backed it up.) That's my opinion, I'm just a poor user of that wretched piece of software.

Hehe.

I could probably go on-and-on,
Read the rest of this comment...

Anyway.

Block what's not rated. It's also important that your filter have a mechanism to request that a site be unblocked

My HS started doing this a few months before I graduated. I was surprised it worked as well as it did - I would've thought it would be blocking a lot of sites because of the whitelist. Anyway, yes, a human verifier who responds quickly (~1 day) is pretty much a necessity with this scheme, but if you use a commercial filtering system they already have a very large database.

There were two problems with the filter. I won't name the filter here because I don't want students to try this and cause problems.

1) Even though it had whitelists on domains and IPs, it did not check the whitelist for one-word domains. A lot of sites really don't care about the host header, or have a sensible default virtual host. That means you can go into /etc/hosts (or its Windows equivalent) and add, e.g., "foo 18.242.0.29" and http://foo/ will work even if http://geminorum.mit.edu/ is blocked.

2) The filter had a really stupid bug (as far as I can tell - I'll probably test this more over Christmas break) that if you didn't send the first significant part of the HTTP header in one packet, it wouldn't detect that it was HTTP traffic and would not invoke the filter. Therefore the packets ["G"] ["ET http://www.porn.com/ HTTP/1.1\n..."] worked perfectly fine. I noticed this with telnet, but it would not be difficult to write a proxy to allow your browser to do the same.

For example, every paragraph in a HyperScope document has a location number, an address corresponding to the paragraph's location in a document. For example, the second paragraph in the top-level of a document has the location number 2. To link to this paragraph, you can use the address:

    http://foo/bar.opml#2

To jump directly to the second paragraph while viewing a document, you can click on the Jump button, type 2, and press Apply.

right. you can't just drop packages, but you could have a lightweight distribution that loads newly required libraries on demand off the network in a transparent manner. that would entail configuring a jdk installation rather than just unzipping it. but from the standpoint of jar files (that use a classpath manifest), the application should see no differences. however, for the JVM itself, i personally think that so much space is wasted elsewhere (music, images, video etc) that the JVM footprint with the total library is really no big deal.

but, it's really a problem when you are dealing with multiple JVM versions, optional addons, and the applications that get run in the VM (which are also multi-versioned). one of the things that makes this harder than it should be is that jar files aren't required to have any relationship to packages. i would have a lot more hair on my head if when jboss said "class not found.. org.jboss.foothingy.Main" i could look for a org.jboss.foothingy-v2.4.2.jar or something.

this boils down to problems with Java side-by-side versioning (for the app and the JVM), dependency management, and modular organization of the JVM and the applications written to it. None of these things are done well in Java at the moment. .NET is taking this issue more seriously with respect to application packaging. This is an idea worth stealing.

It would probably be best if jar files explicitly represented a node in the package tree and each package explicitly stated what it depends on (including the range of intended versions of its dependencies). that way, when you just want to do something simple in say... a Swing App connecting to a JBoss EJB you don't have to wonder if you will eventually get a classnotfound because you didn't include the entire server in the client deployment.

The dependencies from the main class down to all required jars should be reflectable at runtime. In any kind of secure/safety critical OS, you should not even be allowed to install the app until dependencies are completely satisfied. Any case where it is dynamic, provisions need to be made to ensure that you DO in fact have all possible choices either loaded or loadable across the network.

Once you have that, you should be able to have a panel (not unlike a large-scale version of the JavaWebStart cache) where you can see the libraries LibA-vX.Y.Z and navigate their dependencies. The idea would be you would have a JNLP-like mechanism which works the same locally as it does remotely. If you got the initial library off of an URL its dependencies should generally be available at the same place should you need them. But if package name/version actually mean anything, then you can look to see if you already have something satisfying those dependencies in your cache.

-- a jnlp file specifies a jar file and the main class to launch
http://foo/myApp.jnlp's launches com.foo-v2.1.2.jar#com.foo.Main

--the com.foo-v2.1.2 declares its dependencies RELATIVE TO WHERE WE ARE NOW
com.foo-v2.1.2 requires jdk1.5+
com.foo-v2.1.2 requires org.log4j-v3.2.2.jar
org.log4j-v3.2.2.jar requires jdk1.4+ ...

Etc. So if you serve up an application, you should be prepared to serve up the required dependencies or a redirect to a repository that hosts them. Again, .NET assemblies are tackling this sort of problem. It pains me to see that we are allowing jar-hell to ever happen. We should not have classpaths so much as having each jar state its dependencies, where some of these dependencies may be overriden or made more specific (in the manifest of the main launching jar).

You will always have to ship a set of big fat versions of the JVM as long as this issue is not dealt with.

I guess shite performance and security issues aren't really strings.