Re: [dev] Suckless (*NIX|*BSD) Distribution?
I, like many others, distro hopped for a while until I found archlinux. I use it on desktop and server. However, when it comes to laptops I use os x because it would be a waste of time to put any other unix-y os on there and have the same hardware support. Anyways, arch is the last linux distro ill ever use. Very good distro but I am starting to get curious about the cohesiveness of freebsd... Miles --Original Message-- From: Jack Woehr To: dev mail list ReplyTo: dev mail list Subject: Re: [dev] Suckless (*NIX|*BSD) Distribution? Sent: Jun 20, 2009 11:53 There's already a BSD distrib that sucks less. It's called OpenBSD! -- Jack J. Woehr# I run for public office from time to time. It's like http://www.well.com/~jax # working out at the gym, you sweat a lot, don't get http://www.softwoehr.com # anywhere, and you fall asleep easily afterwards. Sent from my BlackBerry
Re: [dev] Re: dwm development continues NOW
I have dual monitors at work so I'm real excited to try this out on monday. My current solution is a custom patched dwm. It works but isn't optimal --Original Message-- From: Anselm R Garbe To: dev mail list ReplyTo: dev mail list Subject: [dev] Re: dwm development continues NOW Sent: Jun 20, 2009 12:27 An initial version of the new xinerama support is committed into hg, it's not finished/polished yet, but the basics are usable already. During the development I decided to have a bar per monitor, instead of just one bar. It's less confusing that way. Monitors are currently selected through pressing Mod1-w, Mod1-e (just two initial keybindings), and clients are assigned to the selected monitor and can be re-assigned using Mod1-Shift-w, Mod1-Shift-e resp. There are several bugs still, esp. related to the floating handling (it's currently possible to have a floating client assigned to a monitor even if it's shown on a totally different monitor). The code will have a lot of polishing and some config.h options will go away possibly... one candidate is topbar. Bug reports welcome. Please don't do code reviews yet, I know that it's ugly and needs polishing. Kind regards, Anselm Sent from my BlackBerry
Re: [dev] XCB: An alternative to Xlib
www.youtube.com/watch?v=-oFxhqYn-g0 Xcb is the "new" version of xlib around the 6th minute --Original Message-- From: Uriel To: dev mail list ReplyTo: dev mail list Subject: Re: [dev] XCB: An alternative to Xlib Sent: Jun 23, 2009 10:03 DSLs are great, but that is no excuse to build systems so insanely broken and complex that you need to generate all of the code to implement a protocol because it is too insanely complex to be done properly. The whole thing stinks way too much of CORBA/SOAP... uriel On Tue, Jun 23, 2009 at 10:25 AM, Donald Chai wrote: > Right, and along those lines, I'll refuse to use Linux because Linus uses > emacs and git while I prefer vim and hg... > > Why not just appreciate that there's a somewhat high-level specification > that's possibly machine verifiable, rather than having to rely on an English > spec? Domain-specific languages are great, though they could have done > better than choose XML for the syntax. > > On Jun 23, 2009, at 1:03 AM, Uriel wrote: > >> Because using XML to generate C code is such a wonderful idea! >> >> I propose we rewrite dwm and wmii in pure xml and then use XSLT to >> generate C code that we can compile. That is what people call progress >> in the software industry! >> >> Erik Naggum[1] would be proud! >> >> uriel >> >> [1] http://harmful.cat-v.org/software/xml/s-exp_vs_XML >> >> On Tue, Jun 23, 2009 at 6:50 AM, Ammar James wrote: >>> >>> Just ran into this. http://en.wikipedia.org/wiki/XCB >>> >>> Any thougths on it being a suckless alternative to Xlib? >>> >>> >> > > > Sent from my BlackBerry
Re: [dev] mapping keyboard buttons to move the mouse?
Post the code --Original Message-- From: hessi...@hessiess.com To: dev mail list ReplyTo: dev mail list Subject: Re: [dev] mapping keyboard buttons to move the mouse? Sent: Aug 26, 2009 21:52 > On Thu, Aug 27, 2009 at 1:46 AM, wrote: >> Thanks for the application suggestions. how can I get the current cursor >> location from the CLI? > > See attached file. > Thanks for that, though I cannot get the cursor to move smoothly, using cli commands, it moves very slowly and jerkily. I guess its becouse a lot of processes are being spawned/killed in a short time period. Il try to reimplement it with C. Sent from my BlackBerry
Re: [dev] Question upgrading dwm
Xinerama ++ /me hugs his 2 monitors On Wed, Sep 23, 2009 at 7:58 AM, David Neu wrote: > On Wed, Sep 23, 2009 at 8:49 AM, Anselm R Garbe wrote: >> Ah that explains a lot. You aren't using dwm-5.6.1, right? You are >> using dwm-5.6? >> The bug you were noticing was fixed in dwm-5.6.1. Not building with >> Xinerama support will do the trick on single head setups as well of >> course. > > Hi Anselm, > > No, actually I'm using dwm-5.6.1, which if recall correctly I grabbed > from the home page link, > http://dl.suckless.org/dwm/dwm-5.6.1.tar.gz. Let me know if there is > something I can try to track down what's going on. > >> What do others think about this proposal? No Xinerama support by default? > Or while it's not difficult to figure out, perhaps a line in README > indicating how to build without Xinerama. > > Cheers, > David > >
Re: [dev] Bottom Stack
On Wed, Oct 7, 2009 at 9:58 AM, David Neu wrote: > Hi, > > The Bottom Stack page lists the status of these patches at dwm 5.6.1, i.e. > > bstack.c (dwm 5.6.1) (20090908) > bstackhoriz.c (dwm 5.6.1) (20090908) > > Can anyone advise what, if anything need to make them work with dwm 5.7.2? > Is it not compiling or did you forget to include bstack in the layouts[] ? > Thanks! > > Cheers, > David > >
Re: [dev] dwm 5.7.2 and pertag patch
yea
Re: [dev] Ada not Rust
On Tue, Apr 20, 2021 at 10:23:35AM -0400, Greg Reagle wrote: > Can someone point me to an article or blog post recommending which of these > sanitize options would be recommended for general daily use? Take your favourite Makefile and add CFLAGS += -fsanitize=address -fsanitize=undefined LDFLAGS += -lasan -lubsan You might also need CFLAGS += -fanalyzer. Then (at least with GCC 10.3.0) it should be as simple as building and running the program.
Re: [dev] Ada not Rust
On Tue, Apr 20, 2021 at 06:45:40AM -0700, Jeremy wrote:
> Regarding readability: in terms of the just the standard libraries, I
> agree that Rust is more readable than C, especially it comes to iterating
> and generics.
impl I {
fn know<'a, How::Someone>(could: &'a Say) -> This<'a>
with A: Straight + Send + Sync + 'a
{ ... }
static
struct this *
is_readable(struct to *me)
{ ... }
Syntactically, Rust's generics are a total mess.
Rust's iteration is even worse. Something that should be a simple
matter of for (i=0;i etywyniel has suggested an implementation of generics in C that use M4:
> https://github.com/etwyniel/c-generics
I really like this. Thanks for linking to it. This is the sort of
thing that we (the programming community in general) need more of:
stepping back from complexity and doing the minimum needed to actually
work *effectively*. Does this have all the features of C++ templates?
Of course not. It has the features one actually needs if one wants
generic data structures (which one probably doesn't need anyway).
> Regarding ISO-standardization: could you explain a bit more about the
> value of this?
Standardisation means there's a document you can read to understand
whether something is a bug in your code, a bug in someone else's code, a
bug in the implementation or (heavens forbid!) a bug in the
specification. ISO-standardisation is the gold standard of
standardisation because the rigorous process behind it ensures that
every necessary detail is fixed down in precise technical writing.
One of the side-benefits of this kind of writing is that it gives people
a language in which to talk about the language. I'm not sure whether
before C standardisation terms like declaration-specifier and declarator
were precisely demarked in the way they are now. But now that they are,
two people using different implementations in different countries with
different backgrounds can establish a consensus on the correct
syntactic interpretation of any piece of code.
Of course in the case of C++, that interpretation might be 'it's
syntactically correct... if the Riemann hypothesis is true'. But it's
better than you can do for Rust, where what is correct behaviour is...
whatever rustc does. Rust evangelists love to talk about how much
undefined behaviour C has, but it only has undefined behaviour because
it has defined behaviour! Undefined behaviour is behaviour that isn't
defined... by the standard. Everything in Rust is undefined behaviour!
> Regarding built-in concurrency: I would argue that pipe(3) & select(3)
> is sufficient for built-in concurrency, though I understand this debate
> is on-going.
+1.
When OOP became trendy in the 80s-90s-00s, almost every
language out there either added an OOP system or an 'Object '
variant was created of it with one. We now near-universally regard this
as a pretty bad idea.
It is my opinion that the profusion of async/await across the
programming world will be viewed in 15 years like the profusion of OOP
across the programming world is viewed now: a bad solution to a problem
("programming in the large" for OOP, "web scale" for async/await) that
doesn't actually really exist!
> I agree that Rust is better at marketing memory ownership. I'd argue
> that Rust is better at marketing as a whole.
> ...
> Rust is an incredibly fun language to write in, and I believe that the
> enthusiasm for it is unparalleled, however, I'm not certain it's doing
> anything better in terms of debugging & static analysis compared to the
> C ecosystem.
Rust is marketed to a... certain kind of person. I don't think I need
to go into detail. As for their enthusiasm, my view is that they're
incredibly enthusiastic and evangelistic about it for one main reason:
it makes them feel smart, and little else does.
---
We'd all be better off if we focused our efforts on tools to make C
programming better. I was thinking today about how useful it would be
to have a way to indicate that a particular variable shouldn't be able
to impact the running time of a function for cryptography purposes.
(Generally, the control flow, resource use or running time of
cryptography-related functions shouldn't depend on secret values, as
those all have the potential to become side channels). If a compiler or
compiler plugin recognised such a directive, it could ensure it didn't
destroy that property. A static analysis tool could check the resulting
object code and warn you. Other tools could verify it with randomised
automated testing, etc.
Generally speaking, these things would be better off as unobtrusive
extensions to C, able to be ignored by a compiler or other tool without
affecting the meaning of the code to retain compatibility. Rust has
many good ideas but it's just not trendy to implement those ideas in C
sadly.
[dev][dmenu] Setting FC_SCALABLE causes slowdowns
I'm working on trying to speed up dmenu rendering in some edgecases. I've sent a patch to the hackers ML about line-length effecting performance. A second issue I'm noticing is that the line within drw.c: FcPatternAddBool(fcpattern, FC_SCALABLE, FcTrue); will cause vast rendering slowdowns based on the input charset. A good example to try is the text in this chinese ebook: curl 'https://www.gutenberg.org/files/24264/24264-0.txt' | dmenu -l 30 -fn Terminus-10 If you set FC_SCALABLE to FcFalse, it seems then the characters are rendered and things are instant (as they should be). So should FC_SCALABLE being FcFalse / unset be the default? Is there another way to speed up rendering outside of dmenu's scope if not? Miles
Re: [dev] [license] gpl issues
On 6 May 2023 8:56:23 pm NZST, "Страхиња Радић" wrote: > But that is pointless to >bring up here, because the reality is that the programmers who made suckless >software mostly picked Expat License (and are calling it "the MIT License"). >It >is irrelevant for non-GPL programs I fork or contribute to, because once the >license is picked, software it applies to can't be relicensed. As far as I understand, if you create a work (A) that is a fork of another work (B), where B is MIT-licensed, nothing stops you from licensing A as GPL. I wouldn't call it "relicensing": you're licensing your own work, A, which happens to be derived from B. You aren't licensing B, which is someone else's work. You do need to credit B's copyright holders of course. Have I got something wrong here? I am no copyright lawyer, that is for sure, so I cannot claim any expertise. Or did you mean something different? >Here we come to my main point: that this is a troll topic, promoting division >and pushing the main suckless principles to the background. Consequently, I >already wrote too much here. I see no trolling in this thread. Suckless people generally seem to respect others' opinions. Nice to see in this day and age! Kind regards, Miles.
Re: [dev] running a shortlink provider
Be careful about running a link shortener. They are very prone to abuse. They don't cost money to run because of bloat but because they require a lot of moderation. Spam is incessant. NearlyFreeSpeech bans very little, but treats link shorteners as equivalent to running a mail server on their service, because they are always found and exploited by spammers. They write: https://faq.nearlyfreespeech.net/section/policy/proxy#proxy >URL shorteners are, unfortunately, a lot more fun to write than they are to >maintain. If you want to set up a URL shortener for your own use, that's fine. >If you let the general public submit URLs to it, expect us to shut it down the >first time it gets exploited. (And it will get exploited.) Properly-run URL >shorteners aren't successful because they have the shortest or cleverest URL, >they're successful because they have a team of people working 24x7 both >proactively and reactively to prevent and mitigate abuse. If you have such a >team, and you want to run a public URL shortener on our service, please >contact us for special arrangements. If you don't have such a team, you'll >have to find another host that's less concerned about the Internet's welfare. Worth bearing in mind. Cheers, Miles.
Re: [dev] Simpler WiFi alternatives
On 24 June 2023 7:13:48 am NZST, fo...@dnmx.org wrote: >I understand what you are talking about... I once told someone "go kill >yourself" or "I you die", never again.. > >I do understand that there are sensitive souls out there, but they are >coal of >a fire which gets started by governments and corporations with their >"moderation tools".. This has nothing to do with governments or censorship. Governments don't care about swearing. They don't care about meandering, low quality messages. They like them. Look at the "big platforms" that are heavily censored. There is no lack of swearing. There is a lot of low quality off-topic trolling. You aren't doing anything anti-censorship by swearing every second word or posting messages without carefully thinking them through. You're just annoying others on the list. You're lowering the quality of the discussion - both with what you say and how you say it. You make broad suggestions about things without giving them any real thought and you present ideas in this meandering way, often full of profanity. The governments of this world are, if anything, in favour of people swearing every second word. They strongly oppose any attempts to create a child-safe internet or subset of the internet away from porn, groomers and foul language. They sometimes seem to want us all to be mindless consumers incapable of serious inquiry. >I suppose my goal was and is to lower their sensitivity, so far, from >personal >experience, I found out that putting the blade straight into the fire for a >prolonged period of time can really harden it. >What I perhaps failed to realize is that not all blades are equal. >Yes, I don't want to be censored on here, and I don't want sensitive >people in >here, but I do want people, so goal should be to somehow change people from >sensitive to insensitive, tolerant. I don't think anyone is shocked by your messages. They just come off as crass. Imagine going to a conference in real life and one of the speakers goes on a 10 min rant filled with swearing and irrelevant material halfway through his talk. Some people might be offended. Most would be thinking "why am I wasting my time on this idiot?". People aren't being "sensitive". They are just adults with time-waster detectors. When every second word is F this and F that, it suggests that you lack the vocabulary and grammar to express yourself properly. That might not always be true, but it is true enough of the time that most people in this world will make that presumption until it has been disproven. >I got a feeling like you and I are somehow connected, like you are me in past >life or something.. perhaps we are all just 1 split consciousness. This sort of stuff adds nothing and just makes you seem weird. >I feel, myself, like I'm at my limit, been for many many months.. due to my >never-ending eye problem.. >Sensitive or not, computers seemed to heal me mentally. Perhaps you should take a bit of a break from the internet. Go outside, breathe the winter/summer air, etc. Kind regards, Miles.
Re: [dev] Suckless filesystems
I wonder whether filesystems could be more layered. You can already do this to some extent with LUKS and LVM on Linux, but could you go further? Rather than having a big monolithic filesystem like ext4, could you run some simpler filesystem that just did journaling, then on top of that one that did files and directories, and so on and so forth. By separating featurs out into layers, you could potentially improve stability a lot by getting rid of the features you don't need, instead of having to replace the whole FS with a completely different one. That being said, I suspect a lot of the code is shared in the kernel already.
Re: [Mail style feedback] ]Re: [dev] Simpler WiFi alternatives [w/ bonus oneliner]
On 1 July 2023 7:50:20 am NZST, fo...@dnmx.org wrote: >Vim is also bloated as hell at over 70 SLOC (including comments and >everything, wc -l).. I'd rather just use pre-installed `vi`.. >I did use Vim in the past. I do miss it, that's why I started my own text >editor that will be (I hope) as minimalistic as Vi, but as functional as Vim. >I seen there's vim-tiny or something? But I don't trust it to be suckless. Don't take the "bloat" meme too far. Not all large programs are bad and not all small programs are good. Vim is a great editor, it is large because editing is a pretty comprehensive activity. You couldn't fit the functionality of vim in a smaller package and I don't think you could build it out of separate Unix-y pieces. You can also compile out a lot of the bloat features like the terminal emulator. Cheers, Miles
Re: [dev] Minimalist software. Should I care?
On 5 July 2023 6:16:34 am NZST, Dave Blanchard wrote: >People on this email list tend to go to an extreme in favoring simplicity >above all else, which is why they release dumpster fires like the ST terminal >emulator for example which has absolutely no features at all, is riddled with >bugs and compatibility problems, and requires extensive patching to add in any >useful features. The developers are also basement-dwelling losers, total >raging assholes who take personal offense to the suggestion that their code >should be better commented or that someone might fork the code to make an >improved version. There is a page on the website advertising all the many patches available to improve st and dwm. Few if any other software projects provide that these days, and are offended by forks. The suckless philosophy embraces forks and patches: they are minimal as a starting point, and you can easily add the features you like. >I tried ST for a time before realizing it was trash and just switched back to >Xterm, the gold standard of functional X11 terminal emulators, which the ST >developers talked shit about, calling "bloated" in their documentation, and >saying the code wasn't good. Actually it is not bloated, the code quality is >much higher than ST (and is actually commented!), It Just Works(TM), and it's >noticeably faster as well when ST is patched with the juvenile "scrollback >buffer support" implementation--which calls malloc() once for every line(!) of >the scrollback buffer. Ok this is obviously just contrarian trolling, nobody who has read xterm's source code thinks it is any good.
Re: [dev] Minimalist software. Should I care?
On 6 July 2023 3:04:47 am NZST, Dave Blanchard wrote: >On Thu, 06 Jul 2023 00:01:43 +1200 >Miles Rout wrote: > >> There is a page on the website advertising all the many patches available to >> improve st and dwm. >> Few if any other software projects provide that these days, and are >> offended by forks. > >Actually few if any other software projects NEED to be patched to provide >basic ass functionality, like you know, SCROLLBACK BUFFERS IN A TERMINAL. Then why do they get new releases adding new features? Personally I don't use terminal emulator scrollback. It gets too confusing to have scrolling inside vim, AND in the terminal multiplexer, AND in the terminal emulator. Too many layers of scrollbacks with unintuitive interactions. It is like having workspaces AND windows AND tabs in your terminal emulator AND tabs in tmux AND tabs in vim. Too many layers of the same functionality with their own keybindings. > That patch is an absolute joke, BTW--again, it calls malloc() for EVERY LINE > of the scrollback buffer! It takes like a second just to open the terminal > with a large scrollback buffer, vs sanely-designed Xterm which starts > instantly! Don't use it then? Maybe that is why it is a patch. >There's also few software packages out there (in the sane real world) that >actually require you to EDIT THE SOURCE CODE AND RECOMPILE just to change >basic options! More's the pity! I wish more software were configurable with a config.h. Configuration file parsing is annoying, as there is no standard. It is annoying for the programmer, but also for the user. What syntax is required in Postfix? Can you generate configuration values using a function? (You can in a C header using simple macros.) Why reinvent the wheel? And it is the source of many security issues. >Want to use a different font in different terminals for different purposes? >Sorry, st doesn't support that feature, or ANY other features, AT ALL, unless >you personally write a patch to do it. Garbage. I have never needed to do that. Why would I want that misfeature in there, causing bugs and issues for me, when 99.9% of people will not do that? If you have some very specialist requirements, you should make them happen. BTW you can easily just compile multiple copies of the binary with different configurations. >> The suckless philosophy embraces forks and patches: > >Bzzt--WRONG. I suggested a fork of st on this list one time and was violently >assaulted as if I was the enemy of mankind. How do you get violently assaulted via email? Kind regards, Rout.
Re: [dev] C variants, compilers and completeness
On 19 August 2023 12:37:23 am NZST, "Страхиња Радић" wrote: >I haven't checked recently, but the most noticeable missing feature of cproc, >as well as some other compilers, were VLAs. When someone writes the support >for >VLAs, cproc & co. will become much more usable. VLAs are optional in the latest C standards and didn't exist at all in C89. They are a misfeature, at least when put on the stack. They're quite useful as a type system feature for index and size calculations though. >The simpler compilers generally work for smaller projects, but for many >existing packages, for now there is no real alternative to GCC and Clang/LLVM. Sadly, this is true. Most software seems to use some extensions from GCC. The only reason clang is usable is that it tries to be bug-compatible with GNU extensions. Something we can all do is try to patch software to be more compatible. If you know that there is software out there that could use only standardised features but uses GNU extensions unnecessarily, consider submitting a patch. That would be better than bloating these small compilers by adding all of GNU's bad ideas. Unfortunately, some people (*cough* systemd *cough*) deliberately use non-standard features in incompatible ways with the object of being incompatible, and for no other reason. But most programmers are saner than that, I think. This would also help those developers: other compilers tend to compile a lot faster than GCC/clang, at the cost of optimisations that are probably turned off during development anyway. Have a nice day, M.
