Posts by TJ1 188 publicly visible posts • joined 16 Jun 2011
I had to dig through the documentation to figure this out for sure. There are several implicit prerequisites that are not-mentioned:
1. It is for local-only sessions (not remote sessions over SSH)
2. Must be using a graphical windowing system of some form
3. Must have a GPU
So for a typical use-case of tmux or screen where one SSH's to a remote (often headless - no GPU) host where the multiplexer is executing this won't help - won't even work.
> It strikes me that if these scripts were surrounded by some update facilities they could become the norm.
Yes, that is what I've done for Debian, integrating it via /etc/kernel/postinst.d/00-module-whitelist (named so it executes before anything else that builds initrd.img) I've also got a script similar to a2enmod/a2dismod to enable/disable individual modules.
I need to add some logging that reports failed module loads so operator/admin can easily identify additional modules that may need white-listing so as not to break usability.
For servers I generally have a start-up service that does `echo 1 > /proc/sys/kernel/modules_disabled` to prevent any further module loads (can't be re-enabled until reboot).
I wrote an alternative to this after taking inspiration from apache2/nginx's conf-available/conf-enabled style. It only exposes the modules actually required. The initial script run maintains the currently loaded modules. After that any additional modules that need to be allowed is done by adding a sym-link.
The setup shell script ( can be found at https://termbin.com/qipd ) does:
0. Point to the kernel version directory:
modpath="${modpath:-${base}/${kver}}"
1. Get the list of currently loaded modules
modlist="$( lsmod | tail --lines +2 | cut -f 1 -d \ )"
2. Create /usr/lib/modules/${kver}/kernel-available/
3. Create hard links to all modules:
"cp --link --archive /usr/lib/modules/${kver}/kernel/ /usr/lib/modules/${kver}/kernel-available
4. Create /usr/lib/modules/${kver}/kernel-enabled/
5. Iterate over the list of loaded modules ( ${modlist} ) and create directories and sym-links:
...
rp="${module_path##*"${kver}"/kernel/}"
mkdir --parents "${modpath}/kernel-enabled/${rp%/*}"
ln --force --symbolic --relative "${modpath}/kernel-available/${rp}" "${modpath}/kernel-enabled/${rp}"
6. Remove the expected directory:
rm --force --recursive "${modpath}/kernel"
7. Keep the existing layout that depmod sees:
ln --symbolic --relative "${modpath}/kernel-enabled" "${modpath}/kernel"
8. Update module.dep:
depmod
Additionally, make /usr/lib/modules/* invisible to Others:
chmod -R o-rwX ${modpath}
CVE-2026-43284
Patches available in mainline and stable trees.
Debian kernel team has been working overnight patching the supported kernels and building. DSA and packages should be published to -security by about 16:00 UTC Friday 8th (signing of kernels for all architectures currently underway).
How does the Federal House of Representatives bill stand with regard to the 10th Amendment? The constitution doesn't delegate identity verification or age-gating to the federal government so that power is reserved to the States and people. I presume there are Supreme Court rulings that extend this kind of power to the Federal government?
"Amazon has obtained approval from the Federal Communications Commission for 3,236 satellites, but must have at least half launched and operating by July 30, 2026, under its current license."
3,236 / 2 = 1,618 - 153 = 1,465 in 8 months means 183 satellites launched every month.
3 launches had 27 satellites and were on ULA Atlas. = 81
Further 3 were 24 satellites on SpaceX Falcon. +72 = 153
Publicly known planned launches into 2026 will add 45 + 27 + 30 + 49 (151) = 304
Assuming those are successful that leaves 1,314 in approximately 6 months or less; 219 each month.
FCC Licence amendment incoming?
From the small amount of information and the revenue targets in the article it sounds like Tang (Founder, chairperson, [ Owner - 100%]) wants/wanted to cash out or IPO to realise some of the value in his shareholding - with the relatively low profits there won't be much in the way of dividends.
The Starlink user terminal (UT a.k.a. dishy or antenna/router) has a Starlink-network /64. The customer router (in bypass mode) or the Starlink LAN-side router/Wifi AP gets a Starlink-customer /64 and in addition the UT offers a /56 prefix.
So each /40 allocation can support up to 64k delegations and the /32 allocations can support up to 16.7M.
If AirDrop is indeed using BLE to 'listen' is it possible this latency isn't actually due to a WiFi channel switch but to going quiet whilst it listens on Bluetooth for other devices? The article isn't clear on this subtle distinction but it'd make sense.
In other words the scenario could be:
1. Every X milliseconds listen for announcements over Bluetooth
2. To ensure no local interference pause Wifi transmissions whilst listening
3. If needing to send via AirDrop transmit announcement over Bluetooth
4. If AWDL announcement or destination device detected switch Wifi to channel 6 and start talking
5. Resume normal Wifi activity
I think it is pretty obvious why DoD pulled this data so suddenly. The DOGE inspired A.I. analysis spotted that that highly confidential data was being publicly shared from F-16, F-17, and F-18. IT say "F-18", ignored the missing 'A, and decided the DoD was sharing vital data from FA-18 aircraft!
The more obvious reason is that as these satellites use microwave to see what is going on under the cloud-tops the USA is now using storms as a cover for military invasion of Greenland, the Panama canal, and other targets on its acquisition list, and so stops sharing this data to prevent giving 'enemies' advance warning that they're coming.
Admittedly I'm the one in robotic mode but as the saying goes "it beats as it sweeps as it cleans" (and it ain't called a Hoover!)
My experience of these automatic vacuum cleaners started with a vastly expensive Roomba for office cleaning that builds a map as it goes - admittedly could be of some use - but then insists on needing an 'app' to interface with it (that requires a 'phone for the 'app') and an Internet connection to relay the data to someone else's servers. So we got to pay about £600 for a spy in the office that was noticeably noisy, couldn't operate at night (it didn't have the "A.I." to tell the alarm system which room it was entering so that zone could have the movement sensors temporarily ignored), and if operating in day-time had to be stopped if anyone was using the telephone due to the noise. We could have added all of those features to our own local management software if the device interface was local.
A year or so later I got a cheap other brand (£150) for home. It is quieter, doesn't spy (only has an infra-red remote control), generally seems to get better results, doubles as the dog's alarm call at 6 a.m., and its random path makes for a great alternative to most television programmes! Oh, and when it collides with an obstacle it does it *quietly* unlike the Roomba.
This is an intriguing and unusual GPL issue, in as much as it is not about copyright in code directly, but copyright ownership of the licence itself. FSF's GNU licenses disallow modification of the licence; they start with: "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed."
The crux of this appeal is AGPL clause 7 "Additional Terms" and its effect when combined with the additional terms added to the Neo4J v3.5 licence. Since Neo4J took a verbatim copy of the AGPL and appended its own terms the combined result (the combined licence) breaches FSF's copyright in the licence itself, (or does it? Did they 'change' the licence text or just add additional terms to the end?) but does that have an effect on the software being covered by the combined licence, and even if that is a breach of FSF's copyright in the licence, does that cancel entirely the copyright licence the code's owner intends to grant (Neo4J is the author and owner of the code) ?
Where this becomes 'interesting' from a legal standpoint is that clause 7 contains this: " You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission."
Neo4J are the authors of the 'covered work' and are the first distributor of the entire code rather than a 'downstream' distributor (e.g. Suhy). Clause 7 reads as if it was intended to deal with downstream distributors adding their own terms when the main body of code was owned by another party.
Looking at the detail I think it could be a Liquid Robotics "Wave Glider" that includes an optional "Solar electric thruster" , see
https://www.liquid-robotics.com/wave-glider/how-it-works/
The handle at the front of the floating solar electric thruster in the banner photo (left side) and the circular 'stub' behind it matches the right side of the Chinese photograph as do the three solar panels and central antenna/warning beacon.
Appleby: It's a deterrent.
PM Hacker: It's a bluff. I probably wouldn't use it.
Appleby: Yes, but they don't know that you probably wouldn't.
PM Hacker: They probably do.
Appleby: Yes, they probably know that you probably wouldn't. But they can't certainly know.
PM Hacker: They probably certainly know that I probably wouldn't.
Appleby: Yes, but even though they probably certainly know that you probably wouldn't, they don't certainly know that, although you probably wouldn't, there is no probability that you certainly would.
PM Hacker: What?
You brought back to my mind this famous and fabulous repartee that Anthony Jay scripted for Yes Prime Minister! Always makes me laugh but it is spot on.
Regarding Ukraine; early in the full-scale war when Russian officials were talking up nuclear weapons threats US SecDef had a "quiet word" with Shoigu (Russian minister of war). Various sources, paraphrased, report that essentially the Russians were told that if they used any kind of nuclear weapon against Ukraine, including contriving a nuclear "accident" at Zaporizhzhia nuclear power plant, a large number of Ukraine's allies (not necessarily under the NATO umbrella) would use conventional weapons to take out the entire Russian black sea fleet and all Russia's command, control and logistics facilities in occupied territories.
"Screen puts a rerouting layer between your terminal window and the computers you're talking to. So, before you connect, you run Screen, then connect"
>
"Screen puts a rerouting layer between your terminal window and the *process(es) you're using*. So, *after* you connect, you run Screen, then run your process(es)"
Surely if you want the remote processes to continue running on (accidental) disconnect, screen (tmux, and similar) are executed on the target where the processes are running. As in:
localhost -> ssh me@remotehost -> remotehost: "screen", "process-to-keep-running" ... 8-< disconnect
localhost -> ssh me@remotehost -> remotehost: "screen -r" *happy-face*
"Filho's request to get information to statically encode file system interface semantics in Rust bindings"
Unless I'm missing something this seems like an impedance mismatch between long-established kernel development practices where the internal API/ABI can and does change frequently, and a relative newcomer wanting to extend the reach of their new internal interfaces and to do that requiring predictable interface semantics (the bindings).
From what I can see Ted and other's, who have been responsible for the code in the major kernel sub-systems for eons, are fundamentally opposed to suddenly having to consider unrelated domain code (Rust isn't really a sub-system since it aspires to be used across the kernel but not sure how else to describe it) that would require either:
1. update the Rust code and bindings if they change the semantics of their sub-system API/ABI themselves - implying needing to master the Rust side to do so
2. be delayed in implementing changes in their sub-system API/ABI waiting for a Rust-domain developer to implement changes in sync with them
I suspect the mismatch is due to the Rust developers background possibly being in higher level library and application coding where static ABI/API are almost guaranteed.
Regarding suits: It is likely as simple as the life support and communications connections to join suits to capsules are specific to the (different manufacturer's) capsules and likely also the suit is tailored to the seat and harness points (I seem to recall each suit is specific to the wearer, too - not one size fits all). It isn't like there is (yet) a need for an RFC, ISO, or BS standard for life-support couplings... or is there?
I wondered that too since as a Debian dev I saw the initial reports of this on IRC and initially thought it was due to some Debian specific packaging, but it turns out this config was added upstream NINE years ago in 2015. Reading between the lines of the commit messages I suspect this is part of the systemd focus on creating/generating, and starting the host with immutable full disk images that include partition table and all file-systems.
Looking at the 2 commits it looks like the original intention was simply to ensure these directories are present on boot, but a side-effect of a --purge is they're also all cleared! Not nice that it could include remote file-system mounts since this specific file includes /srv/ but there's other vital directories listed in the commits (`/var/ anyone ?)
systemd$ git l tmpfiles.d/home.conf
822cd60135 2015-10-22 01:59:25 +0200 N Lennart Poettering tmpfiles.d: change all subvolumes to use quota
fed2b07ebc 2015-04-21 17:43:55 +0200 N Lennart Poettering tmpfiles: make /home and /var btrfs subvolumes by default when booted up with them missing
git show 822cd6013 fed2b07ebc tmpfiles.d/home.conf
commit 822cd601357f6f45d0176ae38fe9f86077462f06
Author: Lennart Poettering <lennart@poettering.net>
Date: Wed Oct 21 19:47:28 2015 +0200
tmpfiles.d: change all subvolumes to use quota
Let's make sure the subvolumes we create fit into a sensible definition
of a quota tree.
diff --git a/tmpfiles.d/home.conf b/tmpfiles.d/home.conf
index aa652b197f..9f25b83392 100644
--- a/tmpfiles.d/home.conf
+++ b/tmpfiles.d/home.conf
@@ -7,5 +7,5 @@
# See tmpfiles.d(5) for details
-v /home 0755 - - -
-v /srv 0755 - - -
+Q /home 0755 - - -
+q /srv 0755 - - -
commit fed2b07ebc9e8694b5b326923356028f464381ce
Author: Lennart Poettering <lennart@poettering.net>
Date: Tue Apr 21 17:28:16 2015 +0200
tmpfiles: make /home and /var btrfs subvolumes by default when booted up with them missing
This way the root subvolume can be left read-only easily, and variable
and user data writable with explicit quota set.
diff --git a/tmpfiles.d/home.conf b/tmpfiles.d/home.conf
new file mode 100644
index 0000000000..aa652b197f
--- /dev/null
+++ b/tmpfiles.d/home.conf
@@ -0,0 +1,11 @@
+# This file is part of systemd.
+#
+# systemd is free software; you can redistribute it and/or modify it
+# under the terms of the GNU Lesser General Public License as published by
+# the Free Software Foundation; either version 2.1 of the License, or
+# (at your option) any later version.
+
+# See tmpfiles.d(5) for details
+
+v /home 0755 - - -
+v /srv 0755 - - -
I doubt it; more likely is that instead of booking a single sale of $1200 the customer switches to subscription and is paying $300 for the quarter, so instant quarterly revenues will appear to be down but, as the article quotes:
"annualized booking values – a metric of commitment to long-term contracts – which rose from $1.2 billion last quarter to $1.9 billion this time around."
Earlier in 2024 Starlink published a document [0] summarising work they're doing on latency - the aim is for an average of less than 20ms. I wrote a reply to a similar article on Hacker News recently that details how Starlink works for those making uninformed comments about it [1] - I'll repeat it here since it makes the unique challenges clear:
For those not aware of how Starlink operates: The customer antenna is called the User Terminal (U.T.) a.k.a. "dish" although all production models are rectangular - only the pre-production beta model is round and dish-like.
The U.T. contains a phased array antenna that can electronically 'steer' the bore-sight (aim) of the transmitted (and received) signal at the current satellite that is in view. In ideal circumstances the U.T. antenna has approximately 110 degrees field of view (~ 35 degrees above each horizon).
The satellites pass from west to east and take approximately 15 seconds to pass through the field of view of the U.T. The satellite forms a beam aimed at a fixed location on the ground - this is called a 'cell'. All U.T. within that area share the radio link that has a fixed bandwidth, so contention is managed by the satellite.
The path length to a satellite directly overhead would be around 550km (in most cases the satellite is slightly north, or slightly south, of the U.T. but for round numbers sake assume 550km).
The path length to a satellite appearing 35 degrees above the horizon (the slant range) is ~ 2568km.
Satellites relay the packets from the U.T. to the (nearest) Earth ground station, so the path length and therefore travel-time will vary enormously over just 15 seconds.
The round-trip for the minimum case is 4 x 550km = 2200km but for the maximal case is 4 x 2568km = 10272km. These equate to a travel time of between 1.8 and 3.6ms per leg, so that gives a hard physical minimum of 4 x 1.8ms = 7.2ms to 4 x 3.6ms = 14.4ms
As more satellites are added to the constellation so the gap between satellites decreases and the angle above horizon at which a satellite is acquired can increase thus shortening the maximum path and lowering the latency.
Starlink has a publicly stated goal of less than 20ms round trip latency and published a report in March 2024 about the engineering efforts to achieve this [0]. Much of the effort that customers see focuses on two issues:
1. reducing latency between ground station and Internet connection point
2. scheduling the radio links between satellite and all U.T.s in its beam area
Starlink balances contention by sometimes restricting and sometimes promoting activation of new U.T.s in each area - this is why on occasion a fully subscribed cell will impose a waiting list on new activations. At other times Starlink will, and does, dynamically change the monthly subscription cost. Recently some areas had their residential price reduce from US$120 to US$90 where others in congested areas had an increase from US$90 to US$120 (in the USA).
[0] https://api.starlink.com/public-files/StarlinkLatency.pdf
[1] https://news.ycombinator.com/item?id=40384959#40388007
Having followed this issue relatively closely the article seems to have gotten the wrong end of the stick on this.
The problem Starlink has is three-fold; it needs government authorised ground-stations in each territory it provides services due to:
1. International Telecommunications Union (ITU)_international agreements and regulations governing Earth-to-Space frequency bands
2. Keeping paths as short as possible via local ground-stations for low latency (aims for < 30ms Round-Trip Time)
3. Avoiding over-subscribing down/up-links to ground-stations from/to satellites
Starlink has either had permissions not yet authorised, refused, or revoked in several countries; amongst them South Africa and Zimbabwe.
As of end of 2023 seven countries were available with another twenty-five scheduled by end of 2024, out of a total of fifty-four countries. [0] It has a global availability map showing status in each country [1]
Due to wanting to avoid confrontation with governments and resultant delays Starlink is warning customers with *static* User Terminal locations, even if on the Roaming Mobile Regional Plan [2], that the plan's terms of service is "... intended for temporary travel and transit — not for permanent use in a location". In particular, "Mobile Regional" is for use within the same continent.
In respect of each User Terminal knowing its own position: they have embedded GNSS receiver and 3-axis compass. In the motorised generation 1 and 2 'standard actuated' User Terminals these are used to aim the bore-sight of the antenna. In the generation 3 and high-performance static units the same is used to direct the placement of the antenna. The location is constantly monitored so that the phased-array beam steering aims and tracks the satellites as they pass from west to east. Each satellite is in view across about 120 degrees of the sky in ideal conditions and its pass lasts no more than 2 minutes before the beam switches to the next satellite.
The location is also used to ensure that ground "cells" (hexagonal areas) are not over-subscribed since that would lead to link contention on the satellite-to-ground-station down/up-links.Satellites aim a beam at each cell; all user-terminals in that cell contend for the fixed bandwidth of the beam.
In respect of dealing with GNSS spoofing, jamming, and interference, there is independent research into using the Starlink satellite signalling to augment GNSS or partially replace it. It is also known that Starlink has, and maybe still is, working on a positioning signal service for the U.S. Department of Defence.
[0] https://nairobichronicle.com/2023/12/10/a-list-of-african-countries-where-starlink-is-either-available-or-soon-to-be-launched/
[1] https://www.starlink.com/map
[2] Starlink {Roaming) Plans
No DevOps here - maturity and hundreds of years of experience!
Take a look at the scribbles on their whiteboard - looks like they have the signal clock (SC freq) and data bit pulse width calculations along with some amplitude compression recovery.
https://www.jpl.nasa.gov/news/nasas-voyager-1-resumes-sending-engineering-updates-to-earth
Nice to see them putting the ACE back in hACkEr !
I don't use the thing but as described in the article this sounds like information generally used by accessibility support tools such as screen readers will be lost - is that the case? In many jurisdictions there is a legal requirement to ensure equal access to services for those with accessibility needs.
ESA publishes some really good high resolution photographs of the STM (Structural and Thermal Model) and in some of them it is possible to see there is a platform that the tubular sunscreen connects to, then a gap, then below it the instruments (this organisation can be seen in some sketch/CAD diagrams of the instruments found elsewhere).
The gap between instruments and platform appears to be covered with flaps of gold foil which in some photographs are unclipped and others partially clipped. It looks likely that when the telescope is oriented such that the solar panels aren't aimed perpendicular to the sun, light can pass the edge of panels and is supposed to be reflected away by the tube and these foil flaps. It is possible that one or more foil flaps isn't correctly overlapping - that would explain why light pollution only occurs at specific angles to the sun.
See this and its list of "Related" images:
https://www.esa.int/ESA_Multimedia/Images/2019/09/Structural_and_thermal_model_of_the_Euclid_satellite12
linux$ grep --exclude-dir=.git -rn '^// SPDX' | cut -f 3 -d \ | tr -d \(\) | sort | uniq --count | sort -rn
11993 GPL-2.0
9562 GPL-2.0-only
5926 GPL-2.0-or-later
3322 GPL-2.0+
511 BSD-3-Clause
309 MIT
273 ISC
120 LGPL-2.1
50 BSD-3-Clause-Clear
29 GPL-1.0+
13 LGPL-2.1+
13 Apache-2.0
7 Zlib
4 LGPL-2.1-or-later
4
3 BSD-2-Clause
2 LGPL-2.0+
... stands for Freedom.
No matter how much freedom of choice you give, someone will always want more. Don't give them that freedom and they'll happily just get on with what they're given (e.g: Apple, Microsoft).
Tinkering with the desktop stuff always strikes me as rearranging the deck-chairs on the Titanic whilst it's sinking :)
Snap is there to allow software publishers to push out frequent changes to their software including more recent library dependencies than are in the 6-monthly Ubuntu releases, and to avoid having to learn Debian style packaging or deal with the discipline of getting their project accepted into Debian (Ubuntu's upstream) so that it flows into Ubuntu.
Some of the issues with snaps and specifically Ubuntu:
0. Critical vulnerabilities in core libraries are fixed once in the apt world and managed by a distro-wide team of maintainers. In Ubuntu there is a dedicated paid security team; in the snap world if multiple snaps embed their own versions of the affected library firstly you may not know, secondly you're reliant on swift and correct fixes and publishing of updates, and thirdly the 'team' responsible for doing those things may only be a single person publishing in their free time.
1. Core packages moving from apt repository to snap, making life difficult if one choses to remove snapd (affects -server (e.g. lxd) as well as -desktop (e.g. gnome))
2. Delivery system (snap store) is closed source. Unable to set up alternatives, or local 'stores', as is possible with apt repositories
3. Canonical controls the delivery mechanism and acts as gatekeeper
3. Mixing of open and closed source packages in the same repository (no pockets so one can easily avoid closed-source for example)
4. Lots of manual work required to obtain source code of open-source packages (see https://merlijn.sebrechts.be/blog/2020-08-17-verify-snap/ ) in contrast to: "apt-get source $package"
5. No easy way to replicate the build environment of a snap and do reproducible builds, in contrast to "apt-get build-dep $package; apt-get source $package; cd $package-$version; fakeroot debian/rules binary"
6. Reporting of bugs is not centralised via bugs.launchpad.net as it is with all Ubuntu apt packages (which also includes all package version build histories, build logs, changelogs, and source repositories)
7. Variable or lack of (professional) support. Ubuntu Advantage / Pro paid support packages do not cover snaps in the same way as they cover the apt repositories. Pro covers 2,300 packages in the Ubuntu Main repo, plus an additional 23,000+ packages in the Ubuntu Universe repository for 10 years. ( https://ubuntu.com/pro )
The whole episode doesn't look good for either side. Some facts that often don't get stated make the current status more understandable.
Although originally a UK company (Autonomy Corporation PLC) it listed its shared on the US NASDAQ exchange so financial oversight was a US concern as well.
Evidence from the various trials and audit reports appears to show that HP C-level and directors curtailed or ignored due diligence reports and advice from their own financial people regarding value
HP offered a 79% premium on the share price when it made its offer in August 2011 (share price ~ US$23.50, offer US$42.11)
In October 2011 HP bought 87.3% of the shares (~242,222,749) for US$10.2 billion (giving the balance sheet valuation of ~US$11.7 billion)
If HP hadn't offered and paid the premium then the value of the company at time of offer was ~US$6.5 billion
HP C-level and directors must have decided that paying 79% premium was worth it based on projected revenues.
Evidence seems to show that methods, information and supporting data for recognising sales, and projected revenues ,was manipulated within Autonomy senior leadership.
Auditors for Autonomy signed off on the accounts that incorporated the disputed methods and information.
Of course there is a contract - what there may not be is a commitment to a minimum length of contract, with the minimum being what you pay in advance for, which is usually a month. In this case the cancellation notice required is 30 days (section 18).
https://www.rebelinternet.uk/hubfs/TermsandConditions.pdf
"Data protection is achieved by using a bit-cover process before frames are grouped into information blocks for encoding. The DVB-S2 short block code [4] is used as the primary forward-error-correction (FEC) mechanism. This provides a fixed 16,200 bit encoded block length based on a combination of LDPC and BCH techniques with resulting rates ranging from 0.19 to 0.88 and supporting approximately 10 dB of link SNR fluctuation for a given symbol rate and modulation.
Codeword data is grouped into symbols and multiplexed across many hops, where a hop is the duration of time a transmission stays at one frequency before “hopping” away to another frequency. The hops are then permuted in time. Together, these features provide increased resistance to transient jamming or interference."
Implementation and Testing of the Protected Tactical Waveform (PTW) Brian J. Wolf, Member, IEEE, and Jacob C. Huang
