Archive Today presently does not, and I'm getting hung up on Captcha tests trying to submit a bug report. Present broken archive: <https://archive.is/Nv9Ik>. If someone else could submit a "Bad Grab" report I'd appreciate it.
(In general, check popular archive tools, such as the Internet Archive (above) or Archive Today, and past a working link rather than griping about individual site access issues.)
Is the entire utcc.utoronto.ca return 403 or just utcc.utoronto.ca/~cks? Maybe it's no longer common knowledge, but the ~string part typically means it's hosted in a way so individual unix users can somewhat control their own environments, sometimes with .htaccess files or other things, and adjust the responses from the web-servers somewhat.
Anyways, the point being that it might not be the university doing it, but an individual user. I guess the former would be kind of shitty, but the latter is maybe ok as individuals should be able to chose freely?
FWIW, both the domain at large + this specific URL seems to work fine for me in Spain.
> [...] An open Internet is a great thing, and it would be nice to have one. But it is now less and less compatible with running systems that are useful to their users. I hate firewalling off large chunks of the net from our mailer, but I would hurt even more from our users fleeing email because of spam. And so I firewall. [...]
One interesting idea, never realized that I know of, was for Hurd. The idea was that 'login' would be a simple utility program. One started a session with no user credentials, and ran 'login' as a command to add credentials to already running processes.
This was not at all how Unices worked, of course, which is likely why it never happened. On Unices it would have needed some sort of shared process credentials structure that could be augmented in place by a privileged process. On the Hurd, it would have required an extra method implemented by the auth server.
On my machines, login is not run any more. It's just a PAM client that provides a very dumb paper-compatible cooked mode terminal user interface, after all. I thought for a long time about writing a PAM client that had a better full screen TUI interface that assumed (gasp!) video terminals. So eventually I did just that.
The site is returning Forbidden for me and they seem to have also blocked archive.* sites. A bit of a mean thing for a public university to do.
Wayback has it: <https://web.archive.org/web/20260602133826/https://utcc.utor...>
Archive Today presently does not, and I'm getting hung up on Captcha tests trying to submit a bug report. Present broken archive: <https://archive.is/Nv9Ik>. If someone else could submit a "Bad Grab" report I'd appreciate it.
(In general, check popular archive tools, such as the Internet Archive (above) or Archive Today, and past a working link rather than griping about individual site access issues.)
Is the entire utcc.utoronto.ca return 403 or just utcc.utoronto.ca/~cks? Maybe it's no longer common knowledge, but the ~string part typically means it's hosted in a way so individual unix users can somewhat control their own environments, sometimes with .htaccess files or other things, and adjust the responses from the web-servers somewhat.
Anyways, the point being that it might not be the university doing it, but an individual user. I guess the former would be kind of shitty, but the latter is maybe ok as individuals should be able to chose freely?
FWIW, both the domain at large + this specific URL seems to work fine for me in Spain.
You got it, it’s just ~cks not letting me in. The University itself is still good.
Got curious, tried to figure out what exactly is being blocked, and came across this, unsure if it just applies to emails, maybe not: https://utcc.utoronto.ca/~cks/space/blog/sysadmin/OnBlocking... (https://hastebin.com/share/fipayoqofo.vbnet)
> [...] An open Internet is a great thing, and it would be nice to have one. But it is now less and less compatible with running systems that are useful to their users. I hate firewalling off large chunks of the net from our mailer, but I would hurt even more from our users fleeing email because of spam. And so I firewall. [...]
Works great for me :)
(Greetngs from germany)
You have to use "su" :)
One interesting idea, never realized that I know of, was for Hurd. The idea was that 'login' would be a simple utility program. One started a session with no user credentials, and ran 'login' as a command to add credentials to already running processes.
This was not at all how Unices worked, of course, which is likely why it never happened. On Unices it would have needed some sort of shared process credentials structure that could be augmented in place by a privileged process. On the Hurd, it would have required an extra method implemented by the auth server.
On my machines, login is not run any more. It's just a PAM client that provides a very dumb paper-compatible cooked mode terminal user interface, after all. I thought for a long time about writing a PAM client that had a better full screen TUI interface that assumed (gasp!) video terminals. So eventually I did just that.