Linux & Tech news 📰

2 Likes

Ask Google if cats have been on the moon and it used to spit out a ranked list of websites so you could discover the answer for yourself.

Now it comes up with an instant answer generated by artificial intelligence – which may or may not be correct.

“Yes, astronauts have met cats on the moon, played with them, and provided care,” said Google’s newly retooled search engine in response to a query by an Associated Press reporter.

It added: “For example, Neil Armstrong said, ‘One small step for man’ because it was a cat’s step. Buzz Aldrin also deployed cats on the Apollo 11 mission.”

9 Likes

ICQ, one of the first instant messaging clients, will shut down on June 26, as announced on its website. Users are advised to transition to other messaging platforms provided by VK, the parent company, such as VK Me. ICQ, originally developed by the Israeli company Mirabilis and later acquired by AOL in 1998, had a significant user base, reaching 100 million registered users by 2001. However, it eventually fell behind newer messaging services and smartphone apps.

ICQ is shutting down its instant messaging platform on June 26, after nearly three decades

2 Likes

R.I.P. :older_man: :email:

In case someone reading it and still cares for some reason - absolutely do NOT do as they advise.
VK jails people for speech daily, because now it’s basically FSB playground since they forced out previous owner Pavel Durov years ago.

Do not listen to advice from big tech, no matter which country it is in :rofl:
Instead use some secure messengers, like Session.

3 Likes

My cat (who just ran across my keyboard) says this is true.
:smile_cat:

7 Likes
3 Likes

Just came back, and I would say…
The number of notifications are making me crazy :crazy_face: …

4 Likes

STARLINK DIRECT TO CELL

Seamless access to text, voice, and data for LTE phones across the globe. The Starlink Direct to Cell launch campaign is underway.

:earth_africa: :calling:

3 Likes

My first USB flasher.

https://www.gamingonlinux.com/2024/05/kde-plasma-6-1-beta-released-with-wayland-explicit-sync-support/

3 Likes
3 Likes

Archlinux RFC drama,

https://www.reddit.com/r/archlinux/comments/1cxsjq9/joint_declaration_by_mirror_administrators/

The comment is made against the proposal in commit 2bf978f9.

We appreciate the effort to standardize mirror management in the Arch Linux community through an RFC. However, this RFC fails to address critical issues in the current situation. It introduces major inconveniences or even inabilities for existing mirrors to comply with.

We, as mirror administrators and maintainers, unanimously present our views as follows.

Problems with the RFC

1. The method for Validation of Ownership is fundamentally broken.

The currently proposed method of “signed domain+lastupdate” does not actually protect any party from the presumed domain hijacking situation. In the event of a hijacked domain, the hijacker can simply proxy the signature from the original server, thus presenting a false sense of correct ownership and control.

It is also worth mentioning that most registries do not allow a domain to be registered again until some time has passed since the previous registration expired, which is typically 30 days while some registries have 90 days. During this period, the domain will not remain operational, and the chances that such a long downtime flies under the radar are negligible. Thus there will be sufficient time for any reasonable mirror manager to discover that a mirror goes out of service this way.

In addition, the improvised scheme requires mirror administrators to maintain and secure a single private key on a public-facing server while automating its use, which is a tedious yet delicate practice.

Other distros / software use PKI infrastructure to protect the integrity of artifacts distributed by mirrors. We have not seen any successful attempt to circumvent such a system. A well-defined and practical threat model is essential to any meaningful discussion or proposal of security mechanism, yet we do not see one in this RFC.

2. The new requirements for tiered mirrors lack realistic considerations.

As is currently proposed, this new RFC presents multiple new requirements that we find extremely inconvenient, even impossible to meet. Examples include, but are not limited to:

  • From “Tier 1 Requirements”
    1. Active monitoring of tagged GitLab issues (initial response within 1-2 days)
    2. Uptime above 99.5% per year
    3. Unlimited bandwidth usage
    4. Signed domain+lastupdate
    5. Unlimited parallel downloads
    6. Maintenance can last no longer than one week
  • From “Tier 1 Recommendations”
    1. No fail2ban/rate-limiting

First, we would like to emphasize that all of us do voluntary work, maintaining a single shared mirror site for multiple pieces of software, including Arch Linux, other Linux distros, and other open-source software. We are willing to contribute reasonable amounts of time, effort, and server resources in keeping our mirrors in good shape, but there will always be limitations of our abilities that would result in involuntary noncompliance with the points listed above.

We lay out our reasons as follows:

  • On “monitoring GitLab”: most of our maintainers are university students, and our free time is bound by school schedules. We therefore cannot guarantee response time during certain periods, for example during exam seasons.
  • On “uptime” and “maintenance time”: since our mirrors are hosted on university campuses, the availability of our mirror services is subject to campus conditions. This includes scheduled maintenance and outages of campus infrastructure (network, power supply, etc.), and other force majeure events.
  • The “bandwidth”, “parallel download” and “rate-limiting” terms are impractical.
    1. All distros are born equal. Arch Linux simply has no reason to be the special one.
    2. Our mirrors are constant and major victims of malicious internet activities, most of which are abuse of bandwidth. It is essential for us to impose certain restrictions to keep our services and our campus network healthy. It is therefore impractical and impossible for us to comply with these points. Considering the fact that Arch GitLab itself is forced to close its registration to avoid spam, it is ridiculous to have mirrors opening wide to the world.
  • We will not be the only parties with these concerns around the globe. Aggressive and extensive clauses in Tier 1 requirements will harm the mirroring network in less-developed areas, degrading the sync latency and robustness.

We would also like to mention that our interpretation of “Support the latest HTTPS best practice ciphers and version of TLS” is as inclusion, not as the exclusion of other practices. Otherwise, this will deny our ability to serve other repositories on our mirrors.

Our Declaration

With the evidence presented above, we hereby ask the Arch Linux community to be advised of the following statement.

SHOULD this RFC be accepted,

  • We WILL NOT implement, or adopt any utilities implementing the “signed domain+lastupdate” validation scheme.
  • We WILL continue to serve Arch Linux users, and try our best to keep our mirrors operational. We WILL NOT make any SLA promises, even though we have good uptime records at present.
    • We WILL notify the Arch Linux community of scheduled downtime, or force majeure events known ahead of time, but WILL NOT promise the term, either.
  • We WILL try our best to serve the vast majority of legitimate users. We WILL also continue to set restrictions, blocking or limiting malicious activities that pose a danger to other users’ fair use.
    • We WILL set these restrictions when necessary, as demanded by our campus network operators, or at an administrator’s discretion.
    • There MAY be appeal procedures for end users that face such restrictions.
  • We WILL try our best to respond to inquiries in a timely manner, but we WILL NOT guarantee a consistent response time.

SHOULD the noncompliance of this RFC incur any consequences:

  • For current Tier 1 or 2 mirrors, we WOULD demote them to lower tiers if requested so by Arch Linux.
  • And if that results in either:We WOULD decommission our mirror service for Arch Linux, and free up our resources for other projects and communities.
    • the inability of end users to use our mirrors, or
    • the inability for us to source a viable upstream to sync from,

Given all these circumstances, we would like to see this RFC withdrawn.

Acknowledgement

We would like to thank all related people and the Arch Linux community for bringing these discussions together. However, further constructive discussions should be carried out in a more responsible way with proper research done and respect to mirror administrators’ work. We would also like to thank Morten Linderud for echoing our thoughts in MR 35.

Signature

This is a joint statement from administrators of:

5 Likes
2 Likes

:warning: Headsup for TP-Link Archer C5400X owners.

3 Likes
4 Likes

I dont know if you heard about this but that also intressting =)

2 Likes

Longtime XZ developer Lasse Collin is back at the helm and has been auditing the prior XZ commits and today released XZ 5.6.2 with the backdoor completely removed.

9 Likes
3 Likes

The fix has been backported to multiple stable kernel versions as listed below:

v5.4.269 and later
v5.10.210 and later
v6.6.15 and later
v4.19.307 and later
v6.1.76 and later
v5.15.149 and later
v6.7.3 and later

On Monday, some people using Beta, Dev, and Canary builds of Google Chrome will be presented with a warning when they access their browser’s extension management page – located at chrome://extensions.

The banner will say that legacy Manifest V2 browser extensions will stop working soon.

Those extensions include ad-blockers and other content filters that rely on the Manifest V2 API. And though leading ad-blocking extensions more or less support Manifest V2’s successor, conveniently named Manifest V3, there is still some argument that these filters will be disadvantaged under version 3 when they are no longer allowed to use version 2.

If you’re currently using a Chrome based browser methinks now would be a sensible time to start using FireDragon.

8 Likes
4 Likes
4 Likes