siebenmann (u/siebenmann)

siebenmann commented on The early Unix history of chown() being restricted to root utcc.utoronto.ca/~cks/spa... · Posted by u/kencausey

heythere22 · 5 months ago

What's the deal with disk quotas? Saw that in the OT as well. Why would you measure folder size seperately for each and every user? Would it not be a lot easier to just use the disk space of a folder regardless of whomever the file belongs to?

siebenmann · 5 months ago

One reason why Unix quotas are generally not maintained and imposed by path is that it's a lot easier to update quotas as things are created, deleted, modified, and so on if the only thing that matters for who gets charged is some attribute of the inode, which you always have available. This was especially the case in the 1980s (when UCB added disk quotas), because that was before kernels tracked name to inode associations in RAM the way they generally do today. (But even today things like hardlinks raise questions.)

(I'm the author of the linked-to article.)

siebenmann commented on I have a GPS bike computer utcc.utoronto.ca/~cks/spa... · Posted by u/speckx

peterldowns · 5 months ago

Would be nice to see an example of one of these cue sheets, I'm curious about the layout.

siebenmann · 5 months ago

I've made a PDF of one of my bike club cue sheets from 2014 and put it at https://www.cs.toronto.edu/~cks/tbn/tbn-gatineau-gallop-2014... ; the GPS route that is more or less equivalent to it is https://ridewithgps.com/routes/28370340 (there may be minor differences because the route is more modern than the cue sheet, but it will give you orientation). The cue sheet is written for a group ride (where the group will stay together) and for people familiar with Toronto, so it might be challenging to follow solo unless you were already somewhat familiar with the ride (as the ride leader is expected to be).

The cue sheet is structured the way it is because it's expected it will be folded in half horizontally to fit in a map/cue sheet holder, and perhaps vertically as well (if people have a small holder; you fold vertically first, initially hiding the entire right column since you only need it after lunch, then horizontally). Cue sheet holders typically let you flip them up to see the back, so the exact division of a horizontal fold doesn't have to be perfect. Each numbered section covers a (relatively) distinct section of the ride to make it easier to keep track of where you are in the cue sheet overall.

Cue sheets for different circumstances need different sorts of structure. For example, for some cue sheets it would be quite important to include the distance (cumulative and/or from the previous cue). In others, such as this one, individually numbered cues and distances to them are mostly distractions.

(I'm the author of the linked-to blog entry, and as you can tell I have Opinions on cue sheet design.)

siebenmann commented on The X Window System didn't immediately have X terminals utcc.utoronto.ca/~cks/spa... · Posted by u/zdw

somat · 9 months ago

The tricky thing about justifying an X terminal is that it requires a nice graphics system and probably a nice cpu to drive that graphics system as well, so really the only thing you don't need is storage. basically it is hard to save money because you are buying most of a nice computer anyway.

siebenmann · 9 months ago

In 1989, the costs appear to have been significantly different, although on a casual search I don't see list prices for eg then-older Sun models like the 3/60. A brand new Sparcstation 1 (also 1989) was far more expensive than an NCD 16 or NCD 19, and a diskless Unix workstation would need more server support and disk space than an X terminal. Today is a different thing, but that's because PC prices have dropped so dramatically.

siebenmann commented on The long (after)life of some of our old fileserver hardware utcc.utoronto.ca/~cks/spa... · Posted by u/rbanffy

liminalsunset · a year ago

https://utcc.utoronto.ca/~cks/space/blog/sysadmin/HowWeSellS...

Perhaps the most interesting (though sort of irrelevant) part from a linked page on the site is that "cloud" storage is being sold as a one-time cost. A great deal (depending on price) if you ask me!

siebenmann · a year ago

Pricing and charging for storage inside an organization is always ultimately a non-technical decision that has to balance who pays for it versus the consequences of it not being paid for. This is especially the case within organizations like universities, which have unusual funding and funding patterns (for instance, one time capex is usually much easier than guaranteed ongoing opex). We (the people providing the disk storage) know that there are ongoing costs to doing so, but the non-technical decision has been made to cover those costs in other ways than charging professors on a recurring basis.

(I'm the author of the linked-to entry.)

siebenmann commented on Union types ('enum types') would be complicated in Go utcc.utoronto.ca/~cks/spa... · Posted by u/misonic

foldr · a year ago

A separate allocation is not forced. The implementation could allocate a block of memory large enough to hold the two pointers for the interface value together with the largest of the types that implements the interface. (You can't do that with an open interface because there's no upper bound, but the idea here is to let you define closed interfaces.)

In cases where there is a lot of variance in the size of the different interface implementations, separate allocations could actually be more memory efficient than a tagged union. In any case, I'm not sure that memory efficiency is the main reason that people miss Rust-style enums in Go.

siebenmann · a year ago

The problem with allocating bit-packed storage is that then you are into the issue where types don't agree on where any pointers are. Interface values solve this today because they are always mono-typed (an interface value always stores two pointers), so the runtime is never forced to know the current pointer-containing shape of a specific interface value. And the values that interface values 'contain' are also always a fixed type, so they can be allocated and maintained with existing GC mechanisms (including special allocation pools for objects without pointers and etc etc).

I agree with you about the overall motivation for Rust-style enums. I just think it's surprisingly complex to get even the memory efficiency advantages, never mind anything more ambitious.

siebenmann commented on Union types ('enum types') would be complicated in Go utcc.utoronto.ca/~cks/spa... · Posted by u/misonic

foldr · a year ago

I think this is mistaken. Go already has a way to represent 'open' union types (interfaces), so all of these runtime problems have already been solved. What's missing is just the type system support to do exhaustive matching on the members of the union. With the addition of generics, 'all' that would be necessary is to make the following a legal variable definition:

    var foo interface {
        struct { A int } | struct { B string }
    }

It currently fails with the following error:

"cannot use type interface{struct{A int} | struct{B string}} outside a type constraint: interface contains type constraints"

siebenmann · a year ago

Interfaces aren't bit-packed and they force storing all values as a separate allocation that the interface contains a pointer to (escape analysis may allow this separate value to be on the stack, along with the interface itself). I believe that Go used to have an optimization where values that fit in a pointer were stored directly in the interface value, but abandoned it, perhaps partly because of the GC 'is it a pointer or not' issue. In my view, some of what people want union types for is exactly efficient bit-packing that uses little or no additional storage, and they'd be unhappy with a 'union values are just interface values' implementation.

(I'm the author of the linked to article.)

siebenmann commented on "Out of Band" network management is not trivial utcc.utoronto.ca/~cks/spa... · Posted by u/DanAtC

ralferoo · 2 years ago

We might be talking at cross-purposes a bit, but also it seems that you're considering a much larger scale than me, and also I hadn't really considered that some people might want to do data-intensive transfers on the management network, e.g. VM snapshots and backups.

Because of how I use it, I was only considering the management port as being for management, and it's separated for security. In the example in the article, there was a management network that was entirely separate from the main network, with a different provider etc. I guess you may have a direct premises-to-premises connection, but I was assuming it'd just be a backup internet connection with a VPN on top of that, so in theory and management network can connect to any other management network, unless its own uplink is severed. Of course, you need ISPs that ultimately have different upstreams.

In the situation that your management network uplink is down, I'd presume that was because of a temporary fault with that ISP, which is different to the provider for your main network uplink. You'd have to be pretty unlucky for that also to be down too. Sure, I can foresee a hypothetical situation where you completely trash the routes of your main network and then by some freak incident your management uplink is also severed. But I think the odds are low, because your aim should be to always have the main network working correctly anyway. If you maintain 99.9% uptime on your main network and your management uplink from another provider is also 99.9%, the likelihood of both being down is 0.0001%.

I'd also never, ever, ever, want a VLAN-based management network, unless that VLAN only exists on your internal routers and is separated up again into individual nets before it goes outside the server rooms. Otherwise, you've completely lost any security benefit of using an isolated network. OTOH, maintaining a parallel backup network on a VLAN that's completely independent to the management network, but which can be easily patched it by someone at that site if you need them to, isn't necessarily a bad thing.

But anyway, these are just my opinions, and it's been a long time since I was last responsible for maintaining a properly large network, so your experience is almost definitely going to be more useful and current than mine.

siebenmann · 2 years ago

Because of our (work) situation, I was thinking of an OOB network with its own dedicated connections between sites, instead of the situation where you can plug each site into a 'management' Internet link with protection for your management traffic. However, once your management network gets into each site, the physical management network at that site needs to worry about redundancy if it's the only way to manage critical things there. You don't want to be locked out of a site's router or firewall or the like because a cheap switch on the management network had its power supply fail (and they're likely to be inexpensive because the management network is usually low usage and low port count).

siebenmann commented on "Out of Band" network management is not trivial utcc.utoronto.ca/~cks/spa... · Posted by u/DanAtC

ralferoo · 2 years ago

From TFA:

> If your OOB network is your only way of managing things, you not only have to build a separate network, you have to make sure it is fully redundant, because otherwise you've created a single point of failure for (some) management.

I'm not sure I necessarily agree with that. You can set up the network in such a way that you can route over the main network as a backup if your OOB network was down but the main network was up. Obviously, it's not quite as simple as sticking a patch cable between the two networks, but it can be close - you have a machine that's always on your OOB network, and it has an additional port that either configures itself over DHCP or has a hard-coded IP for the main net. But the important thing is that you never have that patched in, except for emergencies like your OOB network cable being severed but you still have access to the main network. If that does happen, you plug it in temporarily and use that machine as a proxy. There's no real reason for extra redundancy in the OOB, because if your main uplink is also severed, there's not really much you're going to be usefully configuring anyway!

siebenmann · 2 years ago

In a lot of environments, you can at least choose to restrict what networks can be used to manage equipment; sometimes this is forced on you because the equipment only has a single port it will use for management or must be set to be managed over a single VLAN. Even when it's not forced, you may want to restrict management access as a security measure. If you can't reach a piece of equipment with restricted management access over your management-enabled network or networks, for instance because a fiber link in the middle has failed, you can't manage it (well, remotely, you can usually go there physically to reset or reconfigure it).

You can cross-connect your out of band network to an in-band version of it (give it a VLAN tag, carry it across your regular infrastructure as a backup to its dedicated OOB links, have each location connect the VLAN to the dedicated OOB switches), but this gets increasingly complex as your OOB network itself gets complex (and you still need redundant OOB switches). As part of the complexity, this increases the chances an in-band failure affects your OOB network. For instance, if your OOB network is routed (because it's large), and you use your in-band routers as backup routing to the dedicated OOB routers, and you have an issue where the in-band routers start exporting a zillion routes to everyone they talk to (hi Rogers), you could crash your OOB network routers from the route flood. Oops. You can also do things like mis-configure switches and cross over VLANs, so that the VLAN'd version of your OOB network is suddenly being flooded with another VLAN's traffic.

(I am the author of the original article.)

siebenmann commented on Go's old $GOPATH story for development and dependencies utcc.utoronto.ca/~cks/spa... · Posted by u/ingve

leaveyou · 2 years ago

sorry for the slight off topic but I still don't understand what is the advantage of having the domain hard coded in the name of the module

go mod init example.com/hello

and also hardcoded in all the import statements

import "example.com/hello"

what if you move the code to other domain ? you need to change the module and all the references to it instead of only the references

I find it quite cumbersome/counter intuitive even after all these years.

siebenmann · 2 years ago

The obvious advantage of using domain names and in general URLs as the package names is that the Go project doesn't have to run a registry for package names. Running a registry is both a technical and especially a political challenge, as you must deal with contention over names, people trying to recover access to their names, and so on. By using URLs, the Go project was able to avoid touching all of those issues; instead they're the problem of domain name registries, code hosting providers, and so on.

siebenmann commented on Go's old $GOPATH story for development and dependencies utcc.utoronto.ca/~cks/spa... · Posted by u/ingve

stairlane · 2 years ago

I struggle to see the authors point.

His last sentence:

> It could have worked, at least in theory, in a world where preserving API compatibility (in a broad sense) is much more common than it clearly is (or isn't) in this one.

Is he implying that using vendor packages is more clear that using version tags in a go.mod? That would certainly be the first I’ve ever heard of someone preferring dependency management via vendor packages over a go.mod & ‘go get’.

Personally I absolutely love the way go manages dependencies. I have way more confidence that my old go programs will run with minimal dependency related issues compared to programs written in something like python.

siebenmann · 2 years ago

My badly communicated overall point is that I don't think it's right to say that Go started without any thought about dependency management. Instead, the Go developers had a theory for how it would work (with $GOPATH creating workspaces), but in practice their theory didn't work out (for various reasons). For me, this makes the evolution of Go modules much more interesting, because we can get a window into what didn't work.

(I'm the author of the linked-to entry. I wrote the entry because my impression is that a lot of modern Go programmers don't have this view of pre-module Go, and especially Go when you had to set $GOPATH and it was expected that you'd change it, instead of a default $HOME/go that you used almost all the time.)