convolvatron
convolvatron on Hacker News
when I'm working as an architect, my job is to put myself out of a job by teaching everyone to be an architect - for themselves and for each other. that admixture of high and low level concerns breeds really effective teams. with the side bonus that everyone has a chance to grow into larger responsibilities.
the internet corporations for names and numbers was established specifically to coordinate the for profit registrar model. but sure, an organization like that with a charter to simply manage the namespace directly.
angle grinders run really fast, and even those with speed control just lower total power, not increase torque.
it would have made more sense to just mount the motor and the planetary, but I think the planetary is important here.
I certainly wasn't nominating the US government. something more like international NGO. the us can do whatever it wants with the .us root, just like all the other ISO country code roots.
this is going to be an unpopular opinion, but this was the inevitable result of changing a function with trivial cost and broad social utility (name registration) from a public service to a commercial one. at the time we heard a lot of standard arguments about the innovation and competition that only a market based solution could bring. its really not a surprise that this is the kind of innovation that resulted.
No one thinks that there non-zero corruption in the Democratic Party. but we're at point where things like environmental policy, foreign relations, military alliances, tariffs, wars, and a whole bunch of actually important issues are being decided by how much Trump can extract from the arrangement.
Maybe they're just really good at hiding it, but I don't really remember a time under any administration when we could say something like 'as a country we're now supporting Russia and abandoning Ukraine and our traditional allies in Europe because they offer much better bribes'.
we should be going after corruption by anyone, its extremely corrosive. I don't understand why if that's a concern why we're supposed to be ok with turning it up to 11. Not only outright personal deal making, but the active replacement of foreign governments, state and local officials with people who know how to play that game properly.
What have you got to even begin to claim an equivalence here. Pelosi's stock trades? Biden's sleazy son?
if you didn't have a multi-user operating system running on every node that basically demands this, because of its complexity and fragility, and you had the necessary introspection to look at memory usage and open sockets, and disk bandwidth, and everything else you might need to mange those processes, then the utility of your escape hatch - which also is complicated and fragile, becomes negative.
not always. Asci-red had a distributed version of OSF/1. this wasn't a great design because it was built on distributed shared memory, so it had fault tolerance and performance problems. the MTA had a shared memory monolithic BSD, but that was almost a forced choice.
The Cray T3D had a really nice distributed services model (really kind of a distributed exokernel) that would be worth emulating
on some machines there was an interactive ganged run facility like 'mpirun'. I think even this distinction where there are 'login' or 'service' nodes and anonymous runners would be at least a little structure. I guess you could argue that k8s is this, but it kind of falls short and seems to require a lot of continuous propping up.
I worked on a single system image project that didn't ever get shipped. it turns out that a syscall proxy layer isn't that difficult to implement, and that leaves you with an undisturbed user space.
anyways, there are a whole host of design options that don't look like k8s or slurm. and having spent some time recently on non-hyperscaler clusters, that bottom level of bringup (provisioning, networking management, reporting, fault tolerance, distributed filesystems) is really a nightmare. I think we lost a lot of traction there by raising generations exclusively in someone else's operational context.
maybe we _should_ be thinking about building proper distributed operating systems instead of loose collections of services. we really missed an opportunity to rethink the OS interface for 'the cloud'. or rather we kind of wasted alot time and maybe we should get our shit together and do it properly. no matter how much we chant 'cattle not pets' everyone is still installing individual nodes and logging in and puttering around.
this question always comes up. I personally think the status quo is pretty weak here. I have certainly added a gdb stub to a unikernel before, but that apparently given that it was never used it wasn't the right answer.
people always talk about losing the excellent debugging facilities that linux gives you. if a service crashes in a big cloud environment what is that you do now that works so well. do you think its intractable to implement that in a single-process kernel?
you crossed a really big gap moving from 'communicate' to 'creating policy'. I certainly do not trust Google in particular to write any policies, given that their whole business model is to attempt to sit at the boundaries between consumers and companies, or email senders or recipients, or job seekers and hirers. not a fan of Schumer, but Schumer should be soliciting input from Google, who is free to submit a public white paper, and NIST, and DJB, and citizens groups, and everyone else that might have a stake in the outcome.
I lived in that world, sunos, solaris, unicos, hpux, aix, irix, ultrix. I always found it preferable to have Os and even compiler specific includes for a whatever definitions needs to be different. and I certainly wasn't interested in having a rewrite pass on the makefiles. but it worked well enough when I dug up something on archie.
and then they wrapped it another layer of translation, and then another and I think more. and things started breaking because I needed the right version of autotools, and at some point I started just running "cc *.c -I. -o foo" before even starting to try to use configure, and it usually worked and saved me a lot of screwing around.
its certainly settled down some, but only because everything is really linux. but still we're here more than 30 years later checking for socklen_t.
it was a always a bad plan.
and in what sense is it doing that at all? unlike the US, the signatories arent parachuting into other sovereign countries to effect their laws. they are enforcing their laws within their own borders.
for some reason that's offended the US, who then proceeds to extra-judiciously impose their will on citizens of other sovereign nations who aren't even in the US.
so who is coloring outside the lines here?
more importantly those abstractions were designed to try to make it easier to reason about what was going on for the author, build additional internal abstractions and to allow a reader to follow along and gain an understand of the structure. unless we believe that we can completely punt on having agency over the codebase, then llm code is only as valuable as it is readable.
this process of giving out your 'secrets' (ccn, exp, ccv, zip) to tens of people a day with no other real authentication is inexcusably insecure. and instead of trying to get on top of the problem for real (like an hsm), we have this very half-assed fraud detection and chargeback mechanism that costly, ineffective, and seems to just bury the real issues behind a facade of concern. its been decades that this has been going on, I remain confused as to what incentives the banks have to continue to prop up this farce.
For me QA is tasked with making sure that the product functions as intended. that means coming up with clever test suites to explore the spaces that the developers didn't think to, making sure the coverage for operational problems is adequate, and also long term tracking of performance and memory utilization.
this doesn't sound like your model, and I'm unclear what it means to break a test. maybe test automation, in which case, sure that seems fair game for AI, but that not where the real meat is.
just from first principles its really not. given its propensity to just make shit up and cheat, ai is really useful when there is some kind of formal or exhaustive checking as a wall for it to throw crap at. so if you rigorously define success and spend a bunch of tokens, you could easily save time and money. but if you ask the ai 'is this correct' and it says 'yes!', or even 'no!', then you've really learned nothing. this isn't a can you can kick arbitrarily far down the road.
I think writing tests is a great use of ai, but only if the tests themselves are throughly reviewed or are themselves validated by statements in a formal system.
in that its lovely and highly functional? sure. what disturbs me is that the lit map is wrapped around this large empty room. but the operator would get the same angular view if the whole thing was just somewhat smaller and wrapped more closely around the desk. the use of space here seems extravagant and kind of unsettling
I think it's a kind of like both? it runs as its own guest, but instead of implementing syscalls that are 1:1 with linux, it looks like linux runs as a library, and uses a different more pared down set to take a normal sys call path to the guest. so my guess is not cheaper at all, since instead of the gvisor syscall->vmexit for the common path, its maybe process->sys call to guest->vmexit to hypervisor.
having looked at the briefly, is really a kernel that's meant to take system calls. I think the unikernel terminology is kinda broken. it's explicitly pared down to talk to a hypervisor rather than supporting a lot of hardware drivers. is a unikernel something you link in like a library? then its not. is a unikernel something that's intended to support a single process? then sure.
I build lights with cob modules with phosphor (bridgelux), and unless I screw up the thermal interface, I get many years out of modules that cost < $5 each. one thing is that the thermal paste is too fiddly for most people, voltage/current tends to drift around and 0.5V is a big difference here. mechanically they tend to use a couple different form factors, but not 100%. the 10 watt units I had been using were bigger than the 15w I use now, and the mounting spacing went from 0.75 to 0.71
I would hope that at least some of this would get standardized over time
I've done animations at the Tcl layer before with composition of Tk objects. for little visualizations its just fine, certainly not AAA
every time I get to use lisp syntax I feel a sense of relaxation, as if the background stress of thinking about precedence and the meaning of all these magic sigils and control flow constructs just melts away and I can finally see clearly what's going on. my first professional programming language was lisp, and almost every single project in the 35 years afterwards was C style. but it still feels like home.
I have that same Bosch. for me its just for cutting down ply and making crates and janky stuff, but it has very little torque, tends to cut ragged (slow I guess?) and a yes a shallow cut. a better saw would help a lot here I think.
I always just defined these types in a per-platform portability header myself.
Im not saying arrival order isn't a key consequence of concurrency in many cases, it's just not the same as concurrency itself. I guess the point for me is that when we're programming or when we're using models, we define the partial ordering. so if an event arrives from outside and causes a message to be put in the queue, the read of that event by another thread is still after the external event.
so our job is really to kind of look at all the possible topological sorts of that 'after' ordering, and ensure that they are all correct, and if not, add additional edges by using locks or whatever mechanism.
kind of more interested are techniques like mvcc and crdt, which make _any_ causal ordering of events (topo sort) result in a meaningful answer.
but if you look at classical simd for example, we have concurrency (and parallelism) without additional constraints, because the threads are strongly synchronized at the hardware level.
I don't like the essential characteristic of concurrency being nondeterminism. its really that multiple processes are running concurrently. if we don't have serializing operations, we have arbitrary execution order. but if we do then we can introduce the necessary determinism while still being (largely) concurrent in evaluation. and if those logically concurrent processes are physically concurrent then we have parallelism. so the first is necessary but not sufficient for the latter.
so I find saying that we have one or the other to pretty misleading.
the sandwich shop in dogpatch has been closed for years. their building was remodeled for startups (kind of a meh patchwork of steel panels, some corten and some not), and they tried to move over a couple blocks, but the pandemic got them.
no, its not really learned helplessness, and I don't know the industry that well, but I move a certain amount of scrap and there's methheads all over the neighborhood where I work. once they started being more careful at the scrapyard the tweakers started selling their copper to a guy I call 'mr froggy'. he's around a lot of the time, and he's a larger scale copper thief. I don't know who mr froggy sells to.
I think you even need to be careful about working Al too much during installation. it will bend in one direction just fine, and even back another direction, but after that cracks are going to start developing.