Searching txt.sour.is

Twts matching #software
Sort by: Newest, Oldest, Most Relevant
In-reply-to » PSA: setpriv on Linux supports Landlock.

@prologic@twtxt.net Yeah, it’s not a strong sandbox in jenny’s case, it could still read my SSH private key (in case of an exploit of some sort). But I still like it.

I think my main takeaway is this: Knowing that technologies like Landlock/pledge/unveil exist and knowing that they are very easy to use, will probably nudge me into writing software differently in the future.

jenny was never meant to be sandboxed, so it can’t make great use of it. Future software might be different.

(And this is finally a strong argument for static linking.)

​ Read More
In-reply-to » @movq Yeah, luckily, there is the suckless project. I couldn't live without dmenu!

@lyse@lyse.isobeef.org dmenu is a great example.

There have been several attempts at porting dmenu from X11 to Wayland. Well, not exactly “porting” it, more like rewriting it from scratch. Turns out: It’s not that easy.

dmenu is super fast and reliable. None of the Wayland rewrites are (at least none of the popular ones that I know of). They are either bloated and/or slow.

It takes a lot of discipline and restraint to write simple software and not blow up the codebase. This is much harder than people think. It’s a form of art, really.

​ Read More
In-reply-to » This aggressive auto-logout on my bank’s website 


@lyse@lyse.isobeef.org I do my timetracking in a little Python script, locally. Every now and then, I push the data to our actual service. Problem solved – but it’s a completely unpopular approach, they all want to use the web site. I don’t get it. Then, of course, when it’s down, shit hits the fan. (Luckily, our timetracking software is neither developed nor run by us anymore. It’s a silly cloud service, but the upside is that I’m not responsible anymore. đŸ€·)

Some of our oldschool devs tried to roll out local timetracking once, about 15 years ago. I don’t remember anymore why they failed 


This is developed inhouse, I’m just so glad that we’re not a software engineering company. Oh wait. How embarrassing.

Oh to be anonymous on the internet. That must be nice. 😅

​ Read More
In-reply-to » This aggressive auto-logout on my bank’s website 


@movq@www.uninformativ.de Yeah, it’s a shitshow. MS overconfirms all my prejudices constantly.

Ignoring e-mail after lunch works great, though. :-)

Our timetracking is offline for over a week because of reasons. The responsible bunglers are falling by the skin of their teeth: https://lyse.isobeef.org/tmp/timetracking.png

  1. The error message neither includes the timeframe nor a link to an announcement article.
  2. The HTML page needs to download JS in order to display the fucking error message.
  3. Proper HTTP status codes are clearly only for big losers.
  4. Despite being down, heaps of resources are still fetched.

I find it really fascinating how one can screw up on so many levels. This is developed inhouse, I’m just so glad that we’re not a software engineering company. Oh wait. How embarrassing.

​ Read More
In-reply-to » The lack of suckless-like simple, hackable software these days is appalling.

For example, I reckon software should treat stdout and stderr with care and never output logs or other such garbage to stdout that cannot possibly be useful in a UNIX pipeline 😅

​ Read More
In-reply-to » The lack of suckless-like simple, hackable software these days is appalling.

@movq@www.uninformativ.de Yeah that’s why I’m striking this conversation with you 😅 Not only do I respect your opinion quite highly đŸ€Ł But like you say (and I’ve read their philipshpy) it can be a bit “elitism” for sure. I’m genuinely interested in what we think of as software that “doesn’t suck”. Tb be honest I haven’t really put thought to paper myself, but I reckon if I did, I’d have some opinions/ideas


​ Read More
In-reply-to » The lack of suckless-like simple, hackable software these days is appalling.

@prologic@twtxt.net Hm, I wouldn’t say that. Go code could fall into that category as well.

Maybe this topic could use a blog post / article, that explains what it’s about. I’m finding it hard to really define what “suckless-like software” is. đŸ€” (Their own philosophy focuses too much on elitism, if you ask me.)

​ Read More
In-reply-to » The lack of suckless-like simple, hackable software these days is appalling.

@prologic@twtxt.net Ah, I’m referring to software that’s similar to that of suckless.org: Small, minimal codebases, small tools, but still useful. dmenu is probably the best example and also farbfeld.

Here’s the author of Anubis talking about some of their experiences:

https://xeiaso.net/blog/why-i-use-suckless-tools-2020-06-05/

(You can skip the long config and keybinds part.)

​ Read More
In-reply-to » I bought the “remastered” versions of Grim Fandango and Forsaken on GOG, because they’re super cheap at the moment. Both have native Linux versions.

In all fairness, GOG says that Forsaken is only supported on Ubuntu 16.04 – not current Arch Linux. If you ask me, this just goes to show that Linux is not a good platform for proprietary binary software.

Is it free software, do you have the source code? Then you’re good to go, things can be patched/updated (that can still be a lot of work). But proprietary binary blobs? Very bad idea.

​ Read More
In-reply-to » I did a “lecture”/“workshop” about this at work today. 16-bit DOS, real mode. đŸ’Ÿ Pretty cool and the audience (devs and sysadmins) seemed quite interested. đŸ„ł

@movq@www.uninformativ.de Interesting internal education sessions are way too infrequent here as well. There are a bunch of “knowledge transfer” meetings actually, but 90% of the topics already sound totally boring to me. The other 9% talks turned out to be underwhelming, sadly. I only attended a single one where it was delivered what has been promised. They’re all talks, not real hands-on trainings like you did.

Once a year the security guys organize a really great hacking event, though. Teams can volunteer to hand in their software dev instances and all workmates are invited to hack them and report security vulnerabilities. That’s a lot of fun, but also gets frustrating towards the end when you don’t make any progress. :-) There’s also some actual hands-on training in advance for preparation of the two days. Unfortunately, I missed the last event due to my own project being very stressful at the time.

When I had a Do What You Want Day I also show my direct teammates what I learned in the hopes of this being interesting to them as well. I’m the only one in my team using this opportunity, sadly.

​ Read More

Saw this on Mastodon:

https://racingbunny.com/@mookie/114718466149264471

18 rules of Software Engineering

  1. You will regret complexity when on-call
  2. Stop falling in love with your own code
  3. Everything is a trade-off. There’s no “best” 3. Every line of code you write is a liability 4. Document your decisions and designs
  4. Everyone hates code they didn’t write
  5. Don’t use unnecessary dependencies
  6. Coding standards prevent arguments
  7. Write meaningful commit messages
  8. Don’t ever stop learning new things
  9. Code reviews spread knowledge
  10. Always build for maintainability
  11. Ask for help when you’re stuck
  12. Fix root causes, not symptoms
  13. Software is never completed
  14. Estimates are not promises
  15. Ship early, iterate often
  16. Keep. It. Simple.

Solid list, even though 14 is up for debate in my opinion: Software can be completed. You have a use case / problem, you solve that problem, done. Your software is completed now. There might still be bugs and they should be fixed – but this doesn’t “add” to the program. Don’t use “software is never done” as an excuse to keep adding and adding stuff to your code.

​ Read More
In-reply-to » OpenBSD has the wonderful pledge() and unveil() syscalls:

@movq@www.uninformativ.de That sounds great! (Well, they actually must have recorded the audio with a potato or so.) You talked about pledge(
) and unveil(
) before, right? I somewhere ran across them once before. Never tried them out, but these syscalls seem to be really useful. They also have the potential to make one really rethink about software architecture. I should probably give this a try and see how I can improve my own programs.

​ Read More

When I chose the MIT license for all of my software, I thought:

“Should I use GPL, which I don’t really understand? Is that worth it? Yeah, there is a theoretical possibility that some company might use my code in their proprietary product 
 and then what? Should I sue them to enforce the GPL? I’m not going to do that anyway, so I’ll just use the MIT license.”

And now we have those LLM scrapers and now it’s suddenly a reality that these companies (ab)use my code. I can see it in my logs. I didn’t expect that back then.

GPL wouldn’t help, either, of course. (Regardless, I now think that GPL would have been the better choice anyway.)

I’m honestly considering taking my code and website offline. Maybe make it accessible through some obscure protocol like Gopher or Gemini, but no more HTTP.

(Yes, Anubis might help. Temporarily.)

I’m just tired.

​ Read More
In-reply-to » One thing about my design here is that it would no longer incorporate "regex"-based rules like OWASP, mostly because my experience thus far has taught me that these rules are kind of overly sensitive, produce false positives and I'm not sure they are really very effective. For example, why is the point of performing SQL injection detection at the Edge using a WAF if you already handle SQL properly in the first place? (seriously does anyone still construct SQL queries by hand with effectively printf?!)

@prologic@twtxt.net There have always been and there will always be people who have absolutely no clue what they’re doing. I’ve been 100% one of them when I started. Guaranteed, heaps of new SQL injections are born every single day, numbers rising.

That doesn’t justify all the WAF crap in the first place, though. In my opinion it’s just a filthy plaster applied to an injected wound. The software itself must be secure. Otherwise, don’t put that shit on the internet. Probably not even operate it at all. Nowhere. Fix it or throw it in the bin.

​ Read More

Once or twice a year, I make an effort to switch from dark mode / black terminals to light mode again.

It usually doesn’t end well, because the contrast is just not as good. There’s a reason that things like professional DAWs or CAD software use a dark theme.

With a heavy bold font, it’s much better:

https://movq.de/v/331aa40bde/s.png

My font doesn’t get any bolder than this, though. I’d have to make a new variant of it. Mhh. đŸ€”

​ Read More

revisitando um projeto de hĂĄ 2 anos
erro no build
python do meu OS Ă© agora uma versĂŁo mais recente
incompatĂ­vel com uma das bibliotecas
keeptryingkeepfailing.mp3
a esperança vã de meter um issue no tracker do projeto
må disposição por acabar o dia com prob não resolvido
horas depois Ă  noite, ping
o developer respondeu ao issue
e fez grande commit pra resolver o problema

fuck yeah software livre :szterminal:

​ Read More
In-reply-to » @prologic @bender @eapl.me I think opening another file is a bad idea because it adds complexity to the clients, breaks the single feed and I think keeping legacy clients will be more complex to add new features in the future. A modern approach is important. I'll be honest, I'm a bit tired of the fight around the direct message. Perhaps, we can remove it as an extension and use the alternative @prologic . My suggestion apparently doesn't like to the community. I have no problem with remove it.

@bender@twtxt.net I use it. It’s not the feature I use the most in the fediverse, but I communicate this way with several friends. For example, it’s the main way I talk to the original creator of the twtxt-el repository, the way people greet me for the first time or the way they notify me of some bugs in the software I maintain. I can even tell you that it’s the main way I talk to some maintainers of the Emacs community. If there are any of you reading my words, speak up!
Why not have the same? There are things I want to say to @prologic@twtxt.net in private, why should I have to send him an email or private IRC? Or an public twt.
Of course, here’s a topic we’ve already talked about: what is twtxt for you? For me it will always be a social network, in microblogging format, but an asynchronous way of communicating. And having a tool to control visibility is basic 😄
I look forward to hearing from you @eapl.me@eapl.me !

​ Read More
In-reply-to » @lyse It wasn’t our building, yeah, luckily. But I’m pretty scared it might happen some day. I think I’ll put more effort into preparing for that. But whatever I do, it would be horrific to lose all your stuff and the memories attached to it 


@prologic@twtxt.net @bmallred@staystrong.run Ah, I just found this, didn’t see it before:

https://restic.net/#compatibility

So, yeah, they do use semver and, yes, they’re not at 1.0.0 yet, so things might break on the next restic update 
 but they “promise” to not break things too lightheartedly. Hm, well. 😅 Probably doesn’t make a big difference (they don’t say “don’t use this software until we reach 1.0.0”).

​ Read More

I now subscribed to most feeds in my Go tt reimplementation that I already followed with the old Python tt. Previously, I just had a few feeds for testing purposes in my new config. While transfering, I “dropped” heaps of feeds that appeared to be inactive.

This might motivate me to actually “finish” the new client, so that it could become my daily driver. No need to use the old software stack any longer. Let’s see how bad this goes.

​ Read More
In-reply-to » When will the flat UI craze end? Can I get my buttons, scrollbars, and toolbars back, please?

@movq@www.uninformativ.de Where can I join your club? Although, most software I use is decentish in that regard.

I just noted today that JetBrains improv^Wcompletely fucked up their new commit dialog. There’s no diff anymore where I would also be able to select which changes to stage. I guess from now on I’m going to exclusively commit from only the shell. No bloody git integration anymore. >:-( This is so useless now, unbelievable.

​ Read More
In-reply-to » What does the #twtxt community think about having a p2p database to store all history? This will be managed by Registries.

@prologic@twtxt.net If it develops, and I’m not saying it will happen soon, perhaps Yarn could be connected as an additional node. Implementation would not be difficult for any client or software. It will not only be a backup of twtxt, but it will be the source for search, discovery and network health.

​ Read More
In-reply-to » (#6gfpeea) @prologic We can't agree on this idea because that makes things even more complicated than it already is today. The beauty of twtxt is, you put one file on your server, done. One. Not five million. Granted, there might be archive feeds, so it might be already a bit more, but still faaaaaaar less than one file per message.

If we don’t keep insisting on simplify and “The beauty of twtxt is, you put one file on your server, done. One.”, then people should just use ActivityPub-based software like Mastodon, PixelFed, etc. which are getting a lot of attention and uses migrating to the fediverse from meta/x here in Denmark over the last couple of months.

​ Read More

Hacer software código opensource es desafiante y paulatinamente desgasta a su autor. Todo comienza con pasión y entusiasmo, por supuesto. Si logras repercusión, te enfrentas a una carrera de fondo que muchos terminan abandonando por las demandas constantes de usuarios que, a menudo, no valoran el trabajo ni contribuyen de manera significativa. Por mencionar un caso reciente: Hector Martin. Líder del proyecto Asahi Linux, quien dedicó años a adaptar Linux para los procesadores Apple Silicon, un logro técnico impresionante. Sin embargo, terminó renunciando debido a la presión de usuarios que exigían soporte y mejoras como si fueran clientes pagos.

La mayorĂ­a de los mantenedores no reciben ningĂșn soporte econĂłmico. Solo unos pocos proyectos logran sostenibilidad financiera a travĂ©s de patrocinios, mientras que la mayorĂ­a de los desarrolladores terminan con un segundo empleo no remunerado.

Sin un cambio en la forma en que se valora y apoya los proyectos Opensource, y no solo hablo de las grandes empresas multimillonarias. SerĂ­a una perdida para todos si acabaremos con un ecosistema de software archivado y abandonado.

Ahora te paso la pelota a ti, Âżcuando fue la Ășltima vez que apoyaste a un mantenedor de software opensource?

#opensource #software #sostenibilidad

​ Read More

I read a lot about Clean Code, SOLID, TDD, DDD
 now I’m discovering «A Philosophy of Software Design»  but nobody talks about the importance of the project architecture. Do we depend on the framework to do the work for us?
You know I’m a big fan of Clean Architecture, but I feel alone when I share my thoughts on social media or at work.
You have to think outside the framework.

​ Read More

Yesterday I was doing a lot of research on how #hyperdrive and the #holepunch project work. Would it be possible to use it to make #twtxt an easier gateway for new users? Could we stop using web servers?
My conclusion: We would end up being a #nostr. On the one hand it would become more complex to use, it would force the user to have software installed, and on the other hand the community would need a central proxy to make the routes accessible via HTTP. In other words, it’s not a good idea.
However, it’s an AMAZING technology. I want to start playing with it.

​ Read More
In-reply-to » Are there any good Registry? I like to check the mentions.

I found 2 active Registries: tilde.instite and twtxt.envs.net . I think that is missing a repository or system for them to find each other. It is easy to share registry users. Your work is awesome! Maybe you are supporting twtxt with the pod and software around them. I am very busy with the Emacs client, but I like to work creating my own version of Registry using Django.

​ Read More
In-reply-to » @eapl.me A way to have a more bluesky'ish handles in twtxt could be to take inspiration from Bridgy Fed and say: If NICK = DOMAIN then only show @DOMAIN So instead of @eapl.me@eapl.me it will just be @eapl.me

I’m just having a similar issue with a podcast I just uploaded on Castopod (which supports ActivityPub).

My first thought was creating a subdomain with the name of the podcast mordiscos.eapl.me

Then I watched that the software allows many podcasts in the same domain, so I had to pick a handle:
https://mordiscos.eapl.me/@podcast

So now I have @podcast@mordiscos.eapl.me when this one is ‘more correct’ @mordiscos@podcast.eapl.me or it could even be @mordiscos.eapl.me
I wasn’t aware of all that when I setup Castopod (documentation might improve a lot, IMO)

My point here is that it’s something important to think from the start, otherwise is painful to change if it’s already being used like that.

​ Read More

Btw about social: found very interesting thing about twitter:

The legal basis that X asserts in the filing is not terribly interesting. But what is interesting is that X has decided to involve itself at all, and it highlights that you do not own your followers or your account or anything at all on corporate social media, and it also highlights the fact that Elon Musk’s X is primarily a political project he is using to boost, or stifle, specific viewpoints and help his friends. In the filing, X’s lawyers essentially say—like many other software companies, and, increasingly, device manufacturers as well—that the company’s terms of service grant X’s users a “license” to use the platform but that, ultimately, X owns all accounts on the social network and can do anything that it wants with them.

​ Read More
In-reply-to » Simplified twtxt - I want to suggest some dogmas or commandments for twtxt, from where we can work our way back to how to implement different feature like replies/treads:

@Codebuzz@www.codebuzz.nl Speed is an issue for the client software, not the format itself, but yes I agree that it makes the most sense to append post to the end of the file. I’m referring to the definition that it’s the first url = in the file that is the one that has to be used for the twthash computation, which is a too arbitrary way of defining something that breaks treading time and time again. And this is the case for not using url+date+message = twthash.

​ Read More

More thoughts about changes to twtxt (as if we haven’t had enough thoughts):

  1. There are lots of great ideas here! Is there a benefit to putting them all into one document? Seems to me this could more easily be a bunch of separate efforts that can progress at their own pace:

1a. Better and longer hashes.

1b. New possibly-controversial ideas like edit: and delete: and location-based references as an alternative to hashes.

1c. Best practices, e.g. Content-Type: text/plain; charset=utf-8

1d. Stuff already described at dev.twtxt.net that doesn’t need any changes.

  1. We won’t know what will and won’t work until we try them. So I’m inclined to think of this as a bunch of draft ideas. Maybe later when we’ve seen it play out it could make sense to define a group of recommended twtxt extensions and give them a name.

  2. Another reason for 1 (above) is: I like the current situation where all you need to get started is these two short and simple documents:
    https://twtxt.readthedocs.io/en/latest/user/twtxtfile.html
    https://twtxt.readthedocs.io/en/latest/user/discoverability.html
    and everything else is an extension for anyone interested. (Deprecating non-UTC times seems reasonable to me, though.) Having a big long “twtxt v2” document seems less inviting to people looking for something simple. (@prologic@twtxt.net you mentioned an anonymous comment “you’ve ruined twtxt” and while I don’t completely agree with that commenter’s sentiment, I would feel like twtxt had lost something if it moved away from having a super-simple core.)

  3. All that being said, these are just my opinions, and I’m not doing the work of writing software or drafting proposals. Maybe I will at some point, but until then, if you’re actually implementing things, you’re in charge of what you decide to make, and I’m grateful for the work.

​ Read More

@prologic@twtxt.net Thanks for writing that up!

I hope it can remain a living document (or sequence of draft revisions) for a good long time while we figure out how this stuff works in practice.

I am not sure how I feel about all this being done at once, vs. letting conventions arise.

For example, even today I could reply to twt abc1234 with “(#abc1234) Edit: 
” and I think all you humans would understand it as an edit to (#abc1234). Maybe eventually it would become a common enough convention that clients would start to support it explicitly.

Similarly we could just start using 11-digit hashes. We should iron out whether it’s sha256 or whatever but there’s no need get all the other stuff right at the same time.

I have similar thoughts about how some users could try out location-based replies in a backward-compatible way (append the replyto: stuff after the legacy (#hash) style).

However I recognize that I’m not the one implementing this stuff, and it’s less work to just have everything determined up front.

Misc comments (I haven’t read the whole thing):

  • Did you mean to make hashes hexadecimal? You lose 11 bits that way compared to base32. I’d suggest gaining 11 bits with base64 instead.

  • “Clients MUST preserve the original hash” — do you mean they MUST preserve the original twt?

  • Thanks for phrasing the bit about deletions so neutrally.

  • I don’t like the MUST in “Clients MUST follow the chain of reply-to references
”. If someone writes a client as a 40-line shell script that requires the user to piece together the threading themselves, IMO we shouldn’t declare the client non-conforming just because they didn’t get to all the bells and whistles.

  • Similarly I don’t like the MUST for user agents. For one thing, you might want to fetch a feed without revealing your identty. Also, it raises the bar for a minimal implementation (I’m again thinking again of the 40-line shell script).

  • For “who follows” lists: why must the long, random tokens be only valid for a limited time? Do you have a scenario in mind where they could leak?

  • Why can’t feeds be served over HTTP/1.0? Again, thinking about simple software. I recently tried implementing HTTP/1.1 and it wasn’t too bad, but 1.0 would have been slightly simpler.

  • Why get into the nitty-gritty about caching headers? This seems like generic advice for HTTP servers and clients.

  • I’m a little sad about other protocols being not recommended.

  • I don’t know how I feel about including markdown. I don’t mind too much that yarn users emit twts full of markdown, but I’m more of a plain text kind of person. Also it adds to the length. I wonder if putting a separate document would make more sense; that would also help with the length.

​ Read More

@prologic@twtxt.net Wikipedia claims sha1 is vulnerable to a “chosen-prefix attack”, which I gather means I can write any two twts I like, and then cause them to have the exact same sha1 hash by appending something. I guess a twt ending in random junk might look suspcious, but perhaps the junk could be worked into an image URL like

Image

. If that’s not possible now maybe it will be later.

git only uses sha1 because they’re stuck with it: migrating is very hard. There was an effort to move git to sha256 but I don’t know its status. I think there is progress being made with Game Of Trees, a git clone that uses the same on-disk format.

I can’t imagine any benefit to using sha1, except that maybe some very old software might support sha1 but not sha256.

​ Read More

With all M$’s apps being basically fancy web apps, there is no need to actually install any of their legacy applications locally anymore. Since I am online basically 100% of the time this turns my Office experience in a Chromebook like one. No installs, never outdated software. Just a yearly subscription contribution to worry about.

​ Read More

Since I have these simple, yet effective bash shell commands, which allow me to edit notes, plans, todos and statuses from the terminal, I feel liberated from overly complex software - everything is just text files and applications which come preinstalled on every Linux system.

​ Read More

An official FBI document dated January 2021, obtained by the American association “Property of People” through the Freedom of Information Act.

This document summarizes the possibilities for legal access to data from nine instant messaging services: iMessage, Line, Signal, Telegram, Threema, Viber, WeChat, WhatsApp and Wickr. For each software, different judicial methods are explored, such as subpoena, search warrant, active collection of communications metadata (“Pen Register”) or connection data retention law (“18 USC§2703”). Here, in essence, is the information the FBI says it can retrieve:

  • Apple iMessage: basic subscriber data; in the case of an iPhone user, investigators may be able to get their hands on message content if the user uses iCloud to synchronize iMessage messages or to back up data on their phone.

  • Line: account data (image, username, e-mail address, phone number, Line ID, creation date, usage data, etc.); if the user has not activated end-to-end encryption, investigators can retrieve the texts of exchanges over a seven-day period, but not other data (audio, video, images, location).

  • Signal: date and time of account creation and date of last connection.

  • Telegram: IP address and phone number for investigations into confirmed terrorists, otherwise nothing.

  • Threema: cryptographic fingerprint of phone number and e-mail address, push service tokens if used, public key, account creation date, last connection date.

  • Viber: account data and IP address used to create the account; investigators can also access message history (date, time, source, destination).

  • WeChat: basic data such as name, phone number, e-mail and IP address, but only for non-Chinese users.

  • WhatsApp: the targeted person’s basic data, address book and contacts who have the targeted person in their address book; it is possible to collect message metadata in real time (“Pen Register”); message content can be retrieved via iCloud backups.

  • Wickr: Date and time of account creation, types of terminal on which the application is installed, date of last connection, number of messages exchanged, external identifiers associated with the account (e-mail addresses, telephone numbers), avatar image, data linked to adding or deleting.

TL;DR Signal is the messaging system that provides the least information to investigators.

​ Read More

oh yeah I love software that just dumps giant amounts of data into my home directory without giving me any option of changing where it dumps the data

​ Read More

don’t get me wrong, I love the power of emacs. but it’s a very complex piece of software, which is inherrently brittle. not a problem in the short term, but for some of my more long term tools it’s a consideration.

​ Read More