We.Love.Privacy.Club

feeds.twtxt.net

Tue, Oct 1 6:55AM 2024 (1y ago)

How to Install Command Line Tools in macOS Sequoia & Sonoma
Command Line Tools are an optional component of Xcode that bring a variety of advanced utilities to the Mac command line, including compilers, debuggers, and other essentials for software development and command line tinkering. But not everyone has to be a developer to require Command Line Tools be installed on their Mac, because the suite … [Read More](https://osxdaily.com/2024/09/30/how-install-command-line-tools-macos-sono … ⌘ Read more

⤋ Read More

the-lunduke-journal-of-technology

feeds.twtxt.net

Mon, Sep 30 1:48PM 2024 (1y ago)

Godot Game Engine Enacts Mass “Cleansing” of Non-Woke Supporters
Those who suggest Godot “focus on software” are labeled “filth of humanity” and “toxic pieces of [censored]”. ⌘ Read more

⤋ Read More

falsifian

www.falsifian.org

Sat, Sep 28 11:06AM 2024 (1y ago)

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

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.

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.
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.)
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

the-lunduke-journal-of-technology

feeds.twtxt.net

Sat, Sep 28 4:20AM 2024 (1y ago)

New California Law: Digital Stores Cannot Say “Buy” When They Mean “License”
Tired of “buying” software only to realize you merely have a “license” that can be taken away? ⌘ Read more

⤋ Read More

cncf

feeds.twtxt.net

Thu, Sep 26 1:00AM 2024 (1y ago)

KubeCon + CloudNativeCon North America 2024 co-located event deep dive: AppDeveloperCon
Co-chairs: Naina Singh, Mark Fussell, Evan AndersonNovember 12, 2024Salt Lake City, Utah AppDeveloperCon is specifically targeting software developers who are using cloud native technologies to solve problems for their end-user customers. While much of KubeCon focuses on how… ⌘ Read more

⤋ Read More

falsifian

www.falsifian.org

Mon, Sep 23 9:27AM 2024 (1y ago)

@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

linux_gizmos

feeds.twtxt.net

Sun, Sep 22 5:28AM 2024 (1y ago)

Open-Source Oscilloscope with 1 GS/s High-Speed Data Streaming and Flexible Measurement Capabilities
Crowd Supply recently launched a campaign for ThunderScope, an oscilloscope that combines powerful hardware with open-source software. It captures data at 1 GS/s and streams it to a computer via Thunderbolt, USB4, or PCI Express for real-time processing, offering greater flexibility for complex measurements across various timescales. The Thunde … ⌘ Read more

⤋ Read More

cncf

feeds.twtxt.net

Fri, Sep 20 1:00AM 2024 (1y ago)

Por qué las Empresas y Desarrolladores Deberían Adoptar Tecnologías como gVisor para Aumentar la Seguridad de sus Contenedores
Community post by Gerardo Lopez Falcon En el mundo moderno del desarrollo de software, los contenedores han transformado la forma en que las empresas y los desarrolladores despliegan y administran sus aplicaciones. Sin embargo, con esta nueva tecnología,… ⌘ Read more

⤋ Read More

falsifian

www.falsifian.org

Thu, Sep 19 1:49PM 2024 (1y ago)

@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

Searching We.Love.Privacy.Club