Live data from Hacker News

St – A simple terminal implementation for X

st.suckless.org

131–140 of 223 posts

Re: St – A simple terminal implementation for X

#131

Earlier quoted context omitted.

Not having the skills isn't the thing that should stop someone in either scenario, it's not wanting the skills. Arch is great for a beginner that wants to know how to set up their own bootloader and similar things, you can use Ubuntu for years without gaining that knowledge. Or how much C editing and compiling does the average Unix user happen to run into? There's very little natural progression in computer use, peop…

if you don't like it than fork it

I find in hard to fork human behavior and have anything one might consider a good adoption rate.

Re: St – A simple terminal implementation for X

#133
scrolling through http://git.suckless.org/st/plain/st.c I stumbled upon

    #define LEN(a) (sizeof(a) / sizeof(a)[0])
I know precompiler magic is hard, and my C aint the best

but it makes me wonder if the parens at the end make sense - shouldn't it be something like

    #define LEN(a) (sizeof(a) / sizeof((a)[0]))
also asked here https://stackoverflow.com/questions/42001665/is-this-a-plain...

Re: St – A simple terminal implementation for X

#134
post #62

I can't help myself: suckless sucks. Lots of arbitrary limitations for the code, need to recompile instead of configuration, optimizing for a wrong usage scenario.

I find that most of their software is targeted towards beginner/intermediate hackers. Having to recompile /forces/ you to tinker with the source code. When I was learning how to code I would hack the shit out of my window manager (dwm), I learned a lot of C in the process. When you think about it that way, the "arbitrary limitations" on lines of code and everything else starts to make sense. I agree most of their stu…

> Their browser, surf, doesn't even support tabs as far as I can remember.

There is a general tabbing frontend that allows you to tab all sorts of applications: http://tools.suckless.org/tabbed.

Re: St – A simple terminal implementation for X

#135
post #133

scrolling through http://git.suckless.org/st/plain/st.c I stumbled upon #define LEN(a) (sizeof(a) / sizeof(a)[0]) I know precompiler magic is hard, and my C aint the best but it makes me wonder if the parens at the end make sense - shouldn't it be something like #define LEN(a) (sizeof(a) / sizeof((a)[0])) also asked here https://stackoverflow.com/questions/42001665/is-this-a-plain...

i'm not saying that the way they wrote it makes sense, but you have to remember that sizeof is actually an operator and not a function.

Re: St – A simple terminal implementation for X

#136
post #90
post #71

Earlier quoted context omitted.

Well, I mean that's what they're doing as well. They call features other people use and require "bloat" and pretty much say they all suck. I think it's fair to say suckless code is clean and minimalist. But it definitely isn't suckless.

First of all it is "suck less" not "suckless". ie "less bloat/features" rather than "hey look at our perfect software". This is a point reiterated on their site repeatedly (including the tag on their home page: http://suckless.org/ ) Secondly, it's all very tongue in cheek. After all it's aimed at the OpenBSD crowd and like minded people. It's not really meant to be taken literally by the general computing audience -…

> What happened to respecting our peers and acknowledging the massively wide range of personal preferences and usage habits?

I absolutely wasn't trying to be disparaging of them. I understand that there are people who love their work, and I love some of their software (dmenu).

My point was more toward the parent I was replying to - i.e., that the message from the suck-less crowd that other pieces of software "suck" is just an opinion. In the same way that they think (for example) the KDE desktop sucks, it's allowed to think that their products suck.

But I suppose that it can be seen as disrespectful, and I understand that. There is definitely room for airing one's opinion in a less inflammatory way.

Re: St – A simple terminal implementation for X

#137
post #70

Earlier quoted context omitted.

Not that ridiculous from a developers perspective. All of the software I write use hardcoded constants as config. Then once the app is stable and usable by myself on production environments - and only at that point - do I consider building in a config system or at least a few command line flags. What's more, many developers (myself included) aren't afraid of jumping into someone elses code and modifying it to behave…

> Not that ridiculous from a developers perspective. All of the software I write use hardcoded constants as config. Then once the app is stable and usable by myself on production environments - and only at that point - do I consider building in a config system or at least a few command line flags. Do you not build stuff that needs to run differently on production systems than development systems? Simple things like c…

> Do you not build stuff that needs to run differently on production systems than development systems? Simple things like credentials or connection URLs.

If you're building an MVP then the first and foremost concern is getting a proof of concept product running. However to answer your question I don't really see how editing list of constants in an AOT compiled language is any worse than having to do the same in any of the hundreds of popular web solutions written in languages like PHP where they often embed config as source code variables. It's the same issues with hard coded settings in source code but the difference is how your continuous integration pipeline / code deployment scripts are configured. So it's quite an easy problem to solve once you look at the deployment automation.

Obviously the end goal would be to have readable configuration files for different environments. But pragmatically real world code often ends up being rushed and hacked to meet deadlines rather than nurtured, following industry best practices at every point throughout it's development cycle (assuming your company even has a documented development cycle. Many don't!)

Re: St – A simple terminal implementation for X

#138
post #62

I can't help myself: suckless sucks. Lots of arbitrary limitations for the code, need to recompile instead of configuration, optimizing for a wrong usage scenario.

Even though I can't stand to use their software (or their aesthetic, or their ethos...) I'm very grateful that suckless exists. The source serves as an excellent reference if you want to learn, say, how a (non-trivial) window manager works, or how IRC is implemented in practice, or how to wrap the WebKit/GTK+ interface. The code is usually quite straightforward, and the lack of features/config makes it fast and easy to see what's going on.

Re: St – A simple terminal implementation for X

#139
post #62

I can't help myself: suckless sucks. Lots of arbitrary limitations for the code, need to recompile instead of configuration, optimizing for a wrong usage scenario.

I think the suckless project has correctly identified that a lot of software sucks, but their attempts to make it "suck less" are focusing on the wrong points. A lot of mainstream software is grossly inefficient, bloated and resource-intensive, and that's not necessarily because they're featureful. It's certainly possible to write software that is both featureful and efficient, but suckless aggressively cuts features instead of optimising, to reduce the perception of inefficiency; what's left is not necessarily efficient.

In fact, I don't remember the details now but I recall looking at the source for another one of the suckless applications and finding some pretty inefficient algorithms. I think the other comment here about st being CPU-intensive with high output rates is an example of this.

Ironically, one of the reasons I think mainstream software sucks is because newer versions also tend to remove configurability and features often for the same goal of reducing bloat.

Re: St – A simple terminal implementation for X

#140
post #89
post #61

Earlier quoted context omitted.

Sadly Terminology doesn't have support for 24bit RGB sequences (true color): https://gist.github.com/XVilka/8346728

(main developer of Terminology here) As stated on https://phab.enlightenment.org/T746 , it is not an easy move due to the way the text grid is designed. I might work on it someday.

I love Terminology, and the entire 90s vibe of EFL and Enlightenment generally. So unashamedly not flat design in a world of Jony Ive / Google Material Design conformity.
Post reply on HN