IRC channel logs

<gnucode>is the file locking support much improved/fix on the Hurd?

<gnucode> https://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/file_locking/

<youpi>see, it's marked obsolete

<gnucode>I am asking because the official Hurd manual says that one should ignore the "flock" call on the Hurd, because the Hurd interfaces is not suitable for POSIX locking semantics

<gnucode>gotcha. I am not super familiar with what I should write instead, but youpi, you should see a patch series of mine with some hurd.texi edits soon.

<youpi>the paragraph should probably be replaced by a documentation of the file record interface

<gnucode>I will try to write something, but no guarentees that it will be commit worthy. :)

<damo22>i sped up smp again but its still hanging

<zamfofex>Does anyone happen to know whether Qt programs can run well on the Hurd? I’m planning to see if I can use Ladybird as an alternative to IceCat once I try to switch to the Hurd as my daily driver.

<jab>zamfofex: I use netsurf on the Hurd.

<jab>I had to "port" it. The work that I did not not really upstreamable though.

<jab>I defined "PATH_MAX".

<jab>also I am using the Hurd on a T43 and it works pretty well. About once a week I have to hard shutoff the machine, and fix the filesystem corruption.

<jab>but Emacs works really well.

<jab>X definitely feels slower. probably because we do not have a DRM set up.

<zamfofex>Last time I checked, Netsurf did not support scripting very well. And the support for “modern” CSS (that is used very widely nowadays) was limited. It’s unfortunate, but I don’t think Netsurf would work well for me. Even elements like ‘details’ weren’t supported.

<jab>I have also heard that you can use the Hurd on a X60.

<jab>zamfofex: that is definitely true. Ladybird probably has more manpower pushing it forward.

<jab>netsurf mostly works for me.

<jab>and you are definitely right about the scripting. :) they claim to have minimal javascript support, but I have yet to see a website with any amount of javascript work.

<jab>but I like it, because it is a very lean browser. Since my daily driver only has 2 GB of ram. That's perfect.

<zamfofex>I remember a conversation I had on their channel, and apparently they don’t (or didn’t back then) support updating the DOM after it was shown. So scripts that update the page before it has finished loading “work” (sometimes), but if it updates the page after it finished loading, the changes won’t be seen at all.

<zamfofex>Every time I try to use Ladybird, I’m impressed by how much progress has been made to it. Like, it’s never quite “good enough” for what I need, but it seems to progressively improve very quickly.

<zamfofex>Conversely, I’m increasingly unamused by how long it takes to compile too!

<azert>jab: please send patches upstream for netsurf or everyone will just have to repeat your work

<azert>Defining PATH_MAX is not a sin, that’s what literally every other modern Unix do

<azert>There is nothing bad in doing it, it is just an arbitrary limit, every app have the right to define it

<azert>by not up streaming it, many people

<azert>will not find any browser in the distrais and will just give up

<azert>Others will define PATH_MAX after losing one hour understanding it was just that shitty macro not defined

<janneke>GNU will have no arbitrary limits; what "modern Unix" does is inconsequential

<azert>I’m not arguing that GNU should have it

<azert>I’m arguing that it’s ok to define it to fix an app

<janneke>"Defining PATH_MAX is not a sin"

<janneke>sure, it's not a sin

<janneke>but it shows one's ignorance

<azert>You don’t get my point

<janneke>ah

<janneke>i've sent quite some PATH_MAX patches to upstream

<janneke>and i always try to lift the arbitrary limit on GNU

<janneke>so that upstream can see what a silly choice they made

<azert>That’s a good thing, but it is not automatic

<azert>Sometime apps are designed to have such a limit

<janneke>i've rarely if ever seen that

<azert>in any case it should be the app to support the os and not vice versa

<janneke>doesn't the documentation/wiki have templates/recipes for this?

<janneke>ACTION cannot parse the last message

<azert>I’m never going to follow these recipies

<azert>Because I think it’s a crazy crusade against developers

<azert>To fight against path_max

<azert>You can call me ignorant

<azert>I’m a pragmatist

<azert>And I have good smell for passive aggressive rules

<azert>Path max is good for me

<azert>Please fix the limit of 1024 character in all Hurd string interfaces, that’s a bug that bites

<janneke>azert: you weren't inspired by "GNU shall have no arbirtary limits" when reading the GNU coding standards??

<azert>No I thought that would scare developers

<janneke>i'm not aware of that, but yes, sure, let's fix any arbitrary limite and esp if it hurts!

<janneke>what's scary about using malloc instead of []?

<janneke>ACTION thought that was an enlightened insight

<janneke>(thinking C/C++ here, when using guile you're good)

<azert>Well it is quite scary to me

<janneke>hanwen and i took great care of adhering to 'no arbitrary limits' when we wrote lilypond

<janneke>ah

<janneke>well, you've got to remember to call `free' if your program is long-lived

<janneke>note that at-the

<janneke>oops

<azert>First language I learned was Fortran

<janneke>note that at-the-time many/most music typesetting programs had limits on the number of voices, staves, anything

<azert>Fortran77, that’s what was ysed

<zamfofex>I think the issue isn’t that it’s good to have a limit, but rather the fact that many programs assume this limit exists (or at least the macro), and it takes effort to fix them. When such macro exists on most systems, sometimes it is difficult to convince upstream to actually apply a fix for a niche system.

<janneke>my first language was BASIC, quickly followed by z80 assembly

<azert>Even today in scientific python you normally preallocate arrays with fixed size

<janneke>a fixed size is not necessarily an arbitrary limit, ne?

<azert>Upstream would most of the time accept a patch where path max is defined to 4096

<azert>Just because that ought to be enough to anyone

<zamfofex>Shuffling around ‘malloc’/‘realloc’/‘free’ is “more effort” than just declaring an array. And refactoring it from either to the other can be error prone sometimes.

<janneke>"<azert> Just because that ought to be enough to anyone" we've heard that before, ne?

<azert>Yep

<janneke>sure, if "no arbitrary limits" were easier, rms's message wouldn't have been inspiring

<zamfofex>I don’t think “arbitrary limits” are good, but sometimes you have to be practical. Maybe someone might reach them legitimately if they are low enough, but at some point you have to admit it is impractical.

<janneke>and it would have been the default

<damo22>if GNU shalt have no arbitrary limits, you cant represent any number on a computer, so give up

<janneke>zamfofex: sure...but the "it's easier" excuse card is drawn waaaay too often

<zamfofex>Like, suppose there is a file name limit of 1MB. Maybe it is “arbitary”, but I doubt anyone would get anywhere close to it.

<damo22>s/any/every

<janneke>zamfofex: the funny thing here is, that using a very big arbitrary limit is often much more "expensive" than not using arbirtary limits at all

<janneke>we should try to write the absolute minimum of code in C/C++ anyway, and use Guile by default

<janneke>imvho

<damo22>what about rust

<janneke>what about it?

<damo22>its the most type safe thing ive come across

<janneke>yet another imperative language that's also pretty non-bootstrappable

<janneke>nonsense, guile is *much* more safe

<damo22>i dont know guile

<damo22>but C is highly error prone

<janneke>thou shalt not write imperative code when functional code will do

<janneke>guile is a better lisp

<damo22>write translators in haskell

<janneke>and it's the preferred extension language for GNU

<zamfofex>To Haskell people, Guile is an imperative language!

<janneke>haskell is nice, but it cannot be bootstrapped yet

<zamfofex>I feel like there is value to imperative code. Sometimes it is less nice, but sometimes it is nicer. It depends on what you want to do.

<janneke>and yes, you _can_ write imperative code in Guile -- just dont _do_ that!

<janneke>no

<janneke>resorting to imperative code when it's not _absolutely_ necessary, is a bad choice

<janneke>"we" already knew that in the 60s

<zamfofex>Aren’t build systems in Guix effectively imperative?

<janneke>guix's scheme code is functional, disregarding memoization

<zamfofex>What do you define as “imperative”? To me, it’s just the style of “writing commands in the order for them to be executed”.

<janneke>imperative programming is when you change state

<janneke> https://en.wikipedia.org/wiki/Imperative_programming

<janneke>people are notoriously bad at handling state

<janneke>so i believe that "rust" is an honest stupid mistake at best

<zamfofex>Ah. I understand what you meant now. Well, I don’t think changing state is bad when it’s isolated. It becomes cumbersome and confusing when you change widely‐used state in your program carelessly. But if you use a bit of state in small chunks (in functions or blocks), I don’t think it’s very harmful.

<janneke>sure

<janneke>the smaller the scope, the smaller the potential harm

<zamfofex>You just need to be organised, and make sure you don’t introduce a lot of different behavior to code dependant on global(‐ish) state that people have to keep track of in order to understand what the code is doing, I feel.

<janneke>but also, the smaller the scope, the smaller the need for writing imperative code

<janneke>state is killing

<janneke>try to be stateless at any cost

<janneke>and be _very_ thoughtfull about where you need to manipulate state

<janneke>"we"'ve known this for > 50 years

<janneke>only, in 1970, writing code in lisp had a _big_ performance penalty

<janneke>orders of magnitude bigger than today

<zamfofex>Sometimes it is difficult. I don’t think all programs can be easily modelled statelessly. Not that *they can’t at all*, just sometimes not easily. And sometimes trying to model certain programs to work without state can make it more complicated than it needs to be.

<janneke>sure

<janneke>most programs need a "stateful" part

<janneke>but also, many programs permeate statefullness throughout the whole program

<jab>zert I think youpi encouraged me to "properly" port netsurf the last time I spoke about it. Don't quote me on that, but I thought...

<jab>that youpi wanted me to port netsurf the "proper" way.

<AlmuHS_>jab: Hurd is able to run in more modern laptop than yours. I tested successfully in a ThinkPad T410

<AlmuHS_>and i think that damo22 got runs Hurd in a x220

<AlmuHS_>and, some years ago, Debian GNU/Hurd has other browsers like Arora and Midori

<gnucode`>hello friends!

<GNUmoon`>hello again

<GNUmoon`>GnuMoon was already taken. :(

<nikolar>hello GNUmoon`

<GNUmoon`>nikolar: howdy!

IRC channel logs

2023-09-17.log