X plays an unavoidable central role in the chain. Nowadays, most components of the architecture (udev, evdev, the compositor) have become self-sufficient in accomplishing their individual tasks and therefore do not need X for nothing else than as a dumb data relay. The proponents of #Wayland realised this and decided it would make more sense to replace X altogether with the compositor, thus making the display server and the composite manager become the same thing. https://sgfault.com/post/2016/8/2016-08-22-display-server-primer/
This is a #lisp machine for network protocols. Initially in pursuit of a social forum focused on link sharing.
as #startups and free projects alike rush to implement some #IETF RFC adding only 'but on the web'. I aim to define a modular protocol server which can support an arbitrary number of network protocols as a network daemon. Our POC in this endeavour will be to build an #NNTP -like protocol daemon which gateways to #IPFS storage. The content held in this system can be consumed by arbitrary clients; a web application presenting #reddit -like services would be just one of many potential clients, although it is likely that Gnus for Emacs will be the first one. https://codeberg.org/fade/callisto
quoting @prophet
mli files are mostly used to constrain the visibility of definitions whereas hs-boot files are about allowing mutual recursion between modules (which OCaml doesn't support, even with mli files!)
But the mechanism by which they achieve their goals is nearly identical even though the perception of it is so vastly different.
I guess the conclusion to draw from this is that both sides are wrong: IMO, mli files are not nearly as good as OCamlers think they are, but hs-boot files aren't as ugly as Haskellers think either.
-- prettySrcLoc and prettyCallStack are defined here to avoid hs-boot
-- files. See Note [Definition of CallStack]
Backpack's design is primarily driven by compatibility considerations (“how do we build upon GHC's existing foundation?”), rather than elegance. In particular, Backpack doesn't eliminate those ugly .hs-boot files, it just automates and hides their generation and processing.
Endlessh is an #SSH tarpit that very slowly sends an endless, random SSH banner. It keeps SSH clients locked up for hours or even days at a time. The purpose is to put your real SSH server on another port and then let the script kiddies get stuck in this tarpit instead of bothering a real server. https://github.com/skeeto/endlessh
@oantolin@brokenix they are not meaning sum types as opposed to product types but just commenting on how most languages don’t have sum types so you have to use some other way to encode data with tags or class hierarchies or etc.
pseq combinator is used for sequencing; informally, it eval-
uates its first argument to weak-head normal form, and then eval-
uates its second argument, returning the value of its second argu-
ment. Consider this definition of parMap:
parMap f [] = []
parMap f (x:xs) = y ‘par‘ (ys ‘pseq‘ y:ys)
where y = f x
ys = parMap f xs
The intention here is to spark the evaluation of f x, and then
evaluate parMap f xs, before returning the new list y:ys. The
programmer is hoping to express an ordering of the evaluation: first
spark y, then evaluate ys.
The obvious question is this: why not use #Haskell’s built-in seq
operator instead of pseq? The only guarantee made by seq is that
it is strict in both arguments; that is, seq a ⊥ = ⊥ and seq ⊥
a = ⊥. But this semantic property makes no operational guaran-
tee about order of evaluation. An implementation could impose this
operational guarantee on seq, but that turns out to limit the optimi-
sations that can be applied when the programmer only cares about
the semantic behaviour. Instead, we provide both pseq and seq
(with and without an order-of-evaluation guarantee), to allow the
programmer to say what she wants while leaving the compiler with
as much scope for optimisation as possible. https://simonmar.github.io/bib/papers/multicore-ghc.pdf
fixpoint combinators like Y can't be well-typed in #Haskell. Specifically, something of the form x x requires x to have two conflicting types simultaneously. In dynamic languages, this doesn't matter because you just don't care what the type is, only that you can use the value in some way. But a Haskell compiler does care. However there's no need for such combinators, because Haskell's solution fix f = let x = f x in x is more elegant anyway, and has no typing difficulties (but does require lazy evaluation). #javascript is perhaps not the best launchpad to haskell , to their credit they make good fp presentations https://stackoverflow.com/questions/68975627/translating-a-fixed-point-operator-to-haskell-language
Even if you’re one of the “good devs,” and even if Copilot suddenly makes you twice as productive, as #Microsoft (dubiously) claims, your day didn’t just suddenly get half as long. You just suddenly got twice as many responsibilities https://joshcollinsworth.com/blog/copilot
@brokenix Good post. We already see how GPTs are used to shrink down development teams leading to layoffs. Meaning, the remaining devs have much more work on their hand. Leading to a reduced quality of code, because GPTs still propose code full of errors and the mental load to fix these is much higher. Also, since our brains cannot be twice as fast, it will probably also lead to increased fatigue when I have to do double the work and constantly fight against an error-prone AI.
Where I found AI beneficial for my work as a solo contractor is that I have someone to "talk to" when I make design decisions and need some inspiration, or when I'm desperate in finding an algorithm that solves a problem which I did not encounter before. Or just to confirm that my solution is canonical.
So, as always with technology, it is a double-edged sword and it is up to management to understand the downsides to not overload their remaining devs. Microsoft's marketing is surely not helpful, but that is old news.