Elektrine
EN
Log in Register
Paige Chat Timeline Communities Gallery Videos Email DNS VPN Uptime Kairo
Back to Timeline
Remote

TomAoki

@TomAoki@mastodon.bsd.cafe
mastodon 4.6.5
  • Open on mastodon.bsd.cafe
112 Followers
51 Following
33 Posts
Joined January 12, 2024

Posts

Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Aug 04, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe

Found #NVIDIA released new Production Branch of drivers 595.91.07 and new New Feature Branch of drivers 610.57.04.
https://www.nvidia.com/en-us/drivers/details/277702/
https://www.nvidia.com/en-us/drivers/details/274515/

I've filed Bug297265 (corresponding review is D58639) and Bug297266 (corresponding review is D58640) respectively for upgrading #FreeBSD #ports.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297265
https://reviews.freebsd.org/D58639

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297266
https://reviews.freebsd.org/D58640

0
0
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Jul 22, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @mxchara@seattle.pink
@mxchara@seattle.pink AFAIK, GhostBSD is direct or indirect fork of FreeBSD (IIUC, forked from PC-BSD and its successors, which were forks from FreeBSD at the era, until the upstream switches to Linux) focusing on desktop use-cases. And its ports tree seems to be periodically merging upstream (FreeBSD) ports tree. https://github.com/ghostbsd/ghostbsd-ports/commit/1cc35b1e2a1a6786da5e4d568994cf5277f34a2a Another fork that's worth mentioning would be HardenedBSD, which focuses on security that enables security functionality FreeBSD already has (but cannot make default to avoid POLA violation) as much as possible, with some additional features (upstreamed from time to time). Unlike CheriBSD, it doesn't require CHERIfied CPU to run. https://hardenedbsd.org/
0
0
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Jul 22, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @mxchara@seattle.pink
@mxchara@seattle.pink Using Mate DE on FreeBSD. It's a fork from Gnome2, but Gnome broke their UI quite badly (for me) on Gnome3 and later.
0
1
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Jul 21, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Oops! Overlooked new NFB of #NVIDIA #GPU #drivers 610.43.03 (previous one was 610.43."02"!) for 2 weeks... Filed Bug296950 for upgrading -devel variants https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296950 and opened corresponding review D58375 for #FreeBSD #ports. https://reviews.freebsd.org/D58375 Anyway, seems to be a minor upgrade. https://www.nvidia.com/en-us/drivers/details/274185/ Same Release Highlights for Linux counterpart. https://www.nvidia.com/en-us/drivers/details/274183/
4
0
1
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Jul 08, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @freezr@friendica.myportal.social
@freezr Currently, NVIDIA-related kmods are NOT built on kmod repo except x11/nvidia-kmod, and waiting for admins of kmod builders to look into why. So building x11/nvidia-kmod* and graphics/nvidia-drm-*-kmod* that you have locally is recommended. Don't forget to make /usr/src (at least, /usr/src/sys) to be 100% in sync with your running kernel at least you're using graphics/nvidia-drm-*-kmod*. This is because it depends on LinuxKPI and KBI of LinuxKPI are fragile unlike other parts. OTOH, x11/nvidia-kmod* are relatively robust on kernel updates. It was before I've started maintaining it, but at a minor version upgrades (forgot which it was), I've once forgot to rebuild x11/nvidia-driver (at the moment, x11/nvidia-kmod* weren't yet splitted out from it), but xorg started as if I've NOT forgotton to rebuild it.
2
0
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Jun 25, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to on social.bsdlab.au
@oxy@social.bsdlab.au @dexter@bsd.network Maybe you'll want Insulated electric scissors especially for PoE.😁
3
0
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Jun 19, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Boosted by oxy ::openbsd:: ::freebsd:: ::runbsd:: @oxy@social.bsdlab.au
Replying to on mastodon.social
@FreeBSDFoundation@mastodon.social I've started investigating #FreeBSD at (maybe) since 2.1.6 in conjunction with several other OS'es including #BeOS, #WinNT4, #超漢字(kinda proprietary package of #BTRON with huge font set) with several #Linux distros (Yggdrasil, Vine and Turbo as far as I can recall now). At the era, my personal daily driver was #OS/2. After IBM discontinued OS/2 and the successor, eComStation, didn't actually released Japanese edition (ordered one and obtained English version for temporary use until it's ready, but never happened), I needed to decide which OS to make my NeXT^H^H^H^Hnext daily driver, and switched to FreeBSD, which seemed to be most familiar with me. I've used several GPUs for XFree86 (and Xorg after it landed) on FreeBSD. At first, VGA/SVGA driver was too slow, so I purchased a license of AcceleratedX to use S3 GPUs (and then, Power9000, Matrox MGA,...) and some ATIs(!). When I've switched my daily driver hardware to notebooks, driver for new GPUs were mostly unavailable after AcceleratedX has gone. But fortunately, found that NVIDIA is providing FreeBSD version of drivers for their cutting edge GPUs and ports were already available. After that, I choose PCs having NVIDIA GPUs everytime I need to purchase one. I was happy for a while, but introduction of iGPUs caused headaches. There were too many screams that graphics/drm-*-kmod at their early phase was quite unstable and often broken. So I've always been looking for notebooks that can disable iGPU via BIOS / UEFI, but it became harder and harder. Now I'm using Minisforum MS-01 that allows installing half size, half height PCIeX16 card which doesn't require additional power supply with RTX A400. And noticed that I'm now one of the maintainers for #NVIDIA driver #ports on FreeBSD. Today, latest Production Branch of NVIDIA GPU drivers 595.84 landed onto ports tree at commit ec6b356f6328. https://cgit.freebsd.org/ports/commit/?id=ec6b356f63289da87c9fbb52cdf558805383caf6
3
0
1
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Jun 18, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @grahamperrin@mastodon.bsd.cafe
@grahamperrin@mastodon.bsd.cafe @markmcb@mas.to @thismarkp@mastodon.social Accesible via the link "Documentation portal" at the bottom of the top page, but the route wouldn't be what you want...
0
2
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · May 06, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe

Build fixes for #FreeBSD #ports graphics/drm-61-kmod and graphics/drm-66-kmod are landed. This was the show-stopper.

Now submitted patch to upgrade #NVIDIA #GPU #driver set to 595.71.05 as Bug295058
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295058

and opened corresponding review D56851.
https://reviews.freebsd.org/D56851

This seems to be a bugfix release.
https://www.nvidia.com/en-us/drivers/details/267226/

Info about Linux counterpart is here.
https://www.nvidia.com/en-us/drivers/details/267223/

mastodon.bsd.cafe

BSD.cafe Mastodon Portal

3
0
4
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · May 03, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe

Version 595.71.05 of #NVIDIA #GPU driver sets are released at Apr.28, 2026.

https://www.nvidia.com/en-us/drivers/details/267226/

But patch to upgrade #FreeBSD #ports are now #pending to be submitted until temporary workaround or fixed version for build issues of graphics/drm-61-kmod and graphics/drm-66-kmod reported as Bug 294870 and Bug 294875 is committed.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294870

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294875

Upstream seems to be working on "real fixes", but maybe need some more time to finish. So I've attached a patch for workaround both for Bug 294870 and Bug 294875 at Bug 294870 already (not tested on any branch other than stable/15, though).

4
0
2
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Apr 26, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @tfb@mastodon.bsd.cafe
@tfb@mastodon.bsd.cafe @jrsharp@mastodon.sdf.org #FreeBSD had proceeded some parts of "abstraction" in this several decades. For example, separation of buses (like ISA, PCI, USB, ...) and devices connected to any of the buses called "newbus" when it was introduced, GEOM for disks, NETGRAPH for networks. But the appoaches would be different with #NetBSD. Putting newbus (current implementation) aside, others were for "flexibilities" over "abstraction for compatibilities". My understanding in difference between aproaches of FreeBSD and of NetBSD would be... FreeBSD: Make it work and stable, fast for running platform in production first. Then, consider making it portable. NetBSD: Make it elegant and portable by separating machine independent (MI) parts and machine dependent (MD) parts. Then, making it stable would be easier to achieve. So the next would be performance tunings. Link to document about newbus (already not "new" bus but "current" bus, though): https://docs.freebsd.org/en/books/arch-handbook/newbus/
2
2
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Apr 26, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @tfb@mastodon.bsd.cafe
@tfb@mastodon.bsd.cafe @jrsharp@mastodon.sdf.org Maybe the best approach would be to make UEFI (or its successor) firmware to be hypervisors and all devices to be exposed only as standardized runtime / boottime services. It would minimize porting efforts for open source OS'es (port once, run any compliant hardwares), and allow device manufacturers to be free from "generic device drivers from OS vendors like Micro$oft (or forced to provide driver for them to be supported)" that make it possible (wouldn't be easy, though) to their firmware implementations to match their philosophy (stability centric, performance over stabilities, ...) like in device specific drivers on Win3.x era on PCs.
1
0
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Apr 26, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @jrsharp@mastodon.sdf.org
@jrsharp@mastodon.sdf.org @tfb@mastodon.bsd.cafe IIUC (never actually tried yet, though, as I'm on FreeBSD), NetBSD is good at separating MI / MD parts of archs / drivers, right? If so, it would be easier for NetBSD to keep many archs / drivers for already-not-manufactured devices compared with others. AFAIK, FreeBSD kept on focusing on "actual usabilities for limited archs in the wild", thus, keeping outdated hardware / arch supports to be difficult within limited resources. Most 32bit archs including i386 is dropped to Tier2 (still supported, though) and some were already removed from all supported releases. Only armv7 is kept as Tier2 for all supported releases among other 32bit archs as of quite strong objections from actual devs. (Why i386 is dropped to Tier2 and removed at 15.0 is that it alone uses 32bit time_t and switching it to 64bit makes native i386 support meaningless as of fatal backward compatibility issue.) Luckily, armv7 had 64bit time_t from its beginning (or from quite early phase on porting to it), thus, allowed to kept as Tier2. https://www.freebsd.org/platforms/ Note that i386 binaries can still run on amd64 (aka x86_64 or x64) via compat32 feature, but not sure it can survive 32bit time_t epoch or not.
0
1
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Apr 25, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @jrsharp@mastodon.sdf.org
@jrsharp@mastodon.sdf.org @tfb@mastodon.bsd.cafe I need Gtk2 for Sylpheed (ClawsMail on Gtk3 still has some too rough edges), and Gtk3 for Mate DE and many. And some wants Gtk4 (and parts of which are Gnome apps, although I'm not installing full Gnome4). Hope someone possible fork and maintain Gtk3 (hopefully Gtk2 and Gtk4, too), which clearly beyonds me, and FreeBSD ports to keep Gnome4 "apps" (not mean full DE) working even after Gnome5 and f***** Gtk5 is introduced without X11 support (but not at all installed). Maybe as independent gnome4-* ports or x11 flavors of each.
1
8
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Apr 25, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @chesheer@mastodon.bsd.cafe
@chesheer There had been several discussions for dropping old hardwares on #FreeBSD official MLs (of course about FreeBSD!), not limited with network hardwares. Usually, heads ups are posted at any of (or all of) freebsd-current, freebsd-hackers and/or freebsd-arch ML, then, if sufficient numbers of users who still want the driver kept states "hey, I'm still using it!", it may be kept, otherwise, dropped. So subscribing to any of these (freebsd-current would be preferred for non-developers) MLs is strongly encouraged for anyone understanding "I'm still using hardwares that are already no longer manuactured" not to miss the heads ups. Some causes long discussions. But this is quite sane way, I believe. This is because FreeBSD project doesn't have any "specific single person" (like Linus on Linux) authorized to decide everything the person wants. This kind of discussions are usually held when the driver is "actually" being "removed" from source tree. Some (in case it's possible) would be silently dropped from generic (default) kernel but kept as kernel modules. Kernel modules that devd / devmatch / devfs mechanisms can recognize the hardware and load appropreate modules automatically are still "mostly" like in generic kernel. But if any of the modules is considered vulnerable and no one can fix (as no devs has the hardware to test), it should be blocklisted not to be loaded by default (would need discussions).
4
0
2
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Apr 15, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @lowqualityfacts@mstdn.social
@lowqualityfacts .....Realtek?😅
0
0
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Apr 14, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @darth@silversword.online
@darth@silversword.online Mine is tracking #FreeBSD stable/15, amd64. The computer has main, amd64, too, on another SSD for testing (less frequently updated).
1
0
1
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Apr 13, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @stefano@mastodon.bsd.cafe
@stefano If they call themselves as "Vibe Coding experts", they shall be excellent code reviewers. Otherwise, why can they make built systems "production"?🤣
6
0
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Apr 06, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @ewhac@mastodon.social
@ewhac Although LLMs made coding cheaper, I think total costs of "reliable software developments" becomes more expensive, as of the rapidly increasing costs of "reviewing / auditing" the written codes.
0
0
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Apr 05, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @Suiseiseki@freesoftwareextremist.com
@Suiseiseki@freesoftwareextremist.com @kaia@pleroma.soykaf.com Note that (maybe not for all modes, though), IIRC, some CPUs has interrupt vector table (IVT) starting from address 0x0 and the first one is for storing hard reset (restart) address. And some CPUs had IVT at the end of its physical address space. Ancient memories, so possibly I'm mistaken. In case 0x0 is the reset vector, indirect jump using null pointer (without null pointer checks) may cause the computer to hard-reset.
0
0
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Mar 30, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @nixCraft@mastodon.social
@nixCraft@mastodon.social @novet@infosec.exchange @atoponce@fosstodon.org Anyway, the DNS entry for forums.freebsd.org seems to be removed currently. % drill forums.freebsd.org @1.1.1.1 ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 46711 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; forums.freebsd.org. IN A ;; ANSWER SECTION: forums.freebsd.org. 60 IN A 127.0.0.1 ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: ;; Query time: 13 msec ;; SERVER: 1.1.1.1 ;; WHEN: Tue Mar 31 03:04:59 2026 ;; MSG SIZE rcvd: 52 The answer could be because of local_unbound (running at 127.0.0.1 [localhost]). For some (running) others and parent entry: % drill freebsd.org @1.1.1.1 ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 40850 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; freebsd.org. IN A ;; ANSWER SECTION: freebsd.org. 3600 IN A 96.47.72.84 ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: ;; Query time: 18 msec ;; SERVER: 1.1.1.1 ;; WHEN: Tue Mar 31 03:05:34 2026 ;; MSG SIZE rcvd: 45 % drill bugs.freebsd.org @1.1.1.1 ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 53700 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; bugs.freebsd.org. IN A ;; ANSWER SECTION: bugs.freebsd.org. 60 IN CNAME web3.nyi.freebsd.org. web3.nyi.freebsd.org. 3600 IN A 96.47.72.106 ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: ;; Query time: 35 msec ;; SERVER: 1.1.1.1 ;; WHEN: Tue Mar 31 03:06:29 2026 ;; MSG SIZE rcvd: 73 % drill www.freebsd.org @1.1.1.1 ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 36543 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; www.freebsd.org. IN A ;; ANSWER SECTION: www.freebsd.org. 10 IN CNAME web.geo.freebsd.org. web.geo.freebsd.org. 150 IN A 192.50.199.250 web.geo.freebsd.org. 150 IN A 210.231.212.93 ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: ;; Query time: 174 msec ;; SERVER: 1.1.1.1 ;; WHEN: Tue Mar 31 03:06:02 2026 ;; MSG SIZE rcvd: 87
1
1
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Mar 23, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @camelliakyoto@mastodon.social
@camelliakyoto I love both types, but love Domyoji better.🤤
0
0
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Mar 14, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @oysta@mastodon.oysta.au
@oysta UTF-8 is one of the transmission form of Unicode, and for CJK writers, Unicode has a fatal problem in its standard itself, han unification. At least some of CJK characters are missingly treated as the same character and allocated to the same code point just "it's lookalike". And at least different gryphs of the same character cannot be distinguished. This should have same "base" code point with different selector in character code itself. This already harms on family registers in Japan (no perfect character code schemes yet!). More, some of properly unified character (same meaning) has different gryphs per language, so on any softwares handling plain texts, a text file containing multiple CJK languages cannot be rendered. So selector for languages is mandatory in character code scheme itself. But unfortunately there's no proper character code scheme yet, and Unicode with UTF-8 is the only character encoding that can be an alterntative for future proper one and widely used.
0
0
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Mar 12, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @TomAoki@mastodon.bsd.cafe
Landed as commit 0af72ff3039f33cbd95b8a8f364117181acc635c on main (aka latest) branch of #FreeBSD #ports. https://cgit.freebsd.org/ports/commit/?id=0af72ff3039f33cbd95b8a8f364117181acc635c
2
0
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Mar 11, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe

Found new Production Branch of #NVIDIA #GPU #driver 580.142.

https://www.nvidia.com/en-us/drivers/details/265444/

Linux counterparts for x11/linux-nvidia-libs is:
https://www.nvidia.com/en-us/drivers/details/265443/

Filed Bug 293738 and opened review D55813 to update #FreeBSD #ports.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293738

https://reviews.freebsd.org/D55813

Note that graphics/egl-wayland2 is added as a new dependency for
non-legacy versions of drivers. This is dma-buf based, while
graphics/egl-wayland is EGLStream based.

Let me know if graphics/egl-wayland2 causes new issues
and deinstalling it helps.

4
1
3
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Mar 03, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @david_chisnall@infosec.exchange
@david_chisnall @_elena People who use X would rapidly calm down once Wayland guys stop attempting to kill X11🤣 . ...Ah, you meant former T*tter! M*sk made it toooooo confusing!
0
0
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Feb 14, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @fosdembsd@mastodon.bsd.cafe
@fosdembsd@mastodon.bsd.cafe @mwl@io.mwl.io @emaste@mastodon.social What's important is now it becomes default (currently on main branch only, though). IIRC, there had been a bunch of developments for it after initial import.
0
1
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Feb 06, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @alfonsosiciliano@mastodon.bsd.cafe
@alfonsosiciliano@mastodon.bsd.cafe @FreeBSDFoundation@mastodon.social Not actually ran and not thoroughly read the script in deep, but some points I've noticed: (I'm not subscribing freebsd-desktop ML, nor having GitHub/GitLab accounts) Any actual changes to configurations and installations, it would be better done after "final confirmation" as base installer does (at least, previous installer "sysinstall" did). If allowing to work on already installed systems, checks for already defined values are sufficient or not and modify only when it's insufficient not to make values lower than currently would be wanted. Maybe it would be OK currently, though, at some point, there could be some cutting edge GPUs that are supported only on *-devel variant of nvidia driver ports. So adding "-devel" ones would be wanted by some users. x11/nvidia-kmod, x11/nvidia-driver, x11/linux-nvidia-libs and graphics/nvidia-drm-*-kmod would be upgraded to 590 (or later) series once nvidia releases it as their Production Branch of drivers. And starting from 590 series, support for old GPUs predate Turing generation of architecture are dropped. So at the same time, new legacy branch "-580" is planned to be added.
1
2
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Jan 14, 2026
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @stefano@mastodon.bsd.cafe
@stefano@mastodon.bsd.cafe What they need would be "a huge consulting company having 10s of thousands of consultants that any of them can take anyone's jobs at any time", which should be quite expensive. Otherwise shortage should certainly happen sooner or later. If they really want as they said, it should be REALLY needed and unavoidable costs. But does the huge consulting company can do the jobs better than tha Barista?😅
3
2
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Dec 21, 2025
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @stefano@mastodon.bsd.cafe
@stefano@mastodon.bsd.cafe We shouldn't forget that the movements in memory manufacturers are because datacenter demands pays more compared with consumers demands. It's kinda "race". If consumers pay more, datacenters would pay even more. This means "cost pressures" on datacenters become higher and it should cause the fee for datacenters to be more expensive. So I think keeping data "in premise" being still competitive.
1
0
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Nov 11, 2024
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @meka@bsd.network
@meka@bsd.network @_bapt_@mastodon.social @ifreund@hachyderm.io @FreeBSDFoundation@mastodon.social See Bug 278677 - x11/mate-desktop: fail on start [1] for why dconf-editor is pulled in. [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278677 And why it is built from ports could mean that it is not in the official repo with some reason, usually just under rebuilt (dependencies are updated?) and no pkg found.
0
0
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Oct 13, 2024
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @justine@snac.smithies.me.uk
@justine@snac.smithies.me.uk @pmdj @justine Could see this post via mastodon.bsd.cafe.😀
1
0
0
0
Open post
TomAoki @TomAoki@mastodon.bsd.cafe · Jun 23, 2024
TomAoki
@TomAoki@mastodon.bsd.cafe
mastodon.bsd.cafe
Replying to @raven@mastodon.bsd.cafe
@raven@mastodon.bsd.cafe Using Mate with Compiz just for its excellent mag plugin. #Mate #Compiz
1
0
0
0

Remote instance

mastodon.bsd.cafe
Open on original server
313k7r1n3
Elektrine

Tor hidden service

elekhj7afj4qnrr4yd3bkzslsyo5jgfxw3orgjkhlcxifueodybyiiad.onion

Platform

  • Email
  • Chat
  • Timeline
  • Communities
  • VPN
  • DNS

Company

  • About
  • Contact
  • FAQ

Legal

  • Terms of Service
  • Privacy Policy
  • Warrant Canary
  • Lite (no JS)
  • VPN Policy
  • Source code

Support

  • support@elektrine.com
  • Report Security Issue
Mail client setup IMAP mail.elektrine.com:993 POP3 mail.elektrine.com:995 SMTP mail.elektrine.com:465
© 2026 Elektrine. All rights reserved. Server: 19:12:28 UTC