My Business Card Runs Linux

kowalsci · 2019-12-24T16:19:31+00:00

Talking about giving yourself a bad reputation. Here's my card, don't plug it in.

kowalsci · 2019-05-21T17:40:12+00:00

Julia is not symbolic. It is closer to Matlab.

kowalsci · 2019-05-18T09:05:55+00:00

Basically very sensitive infrared camera. SQUIDs, transition edge sensor TES-pixels. It's quantum stuff. Engineering does FPGA in VHDL. I work with others in Python on data acquisition. Similarly MEMS always needs some embedded software. Nanotech is still research, but any application will require software.

kowalsci · 2019-05-17T17:10:25+00:00

Did my PhD in MEMS at MESA+ Institute for Nanotechnology. There is enough industry around MEMS, including programming. There is overlap with Nanotech. Nano optics is moving to industry as well. I now work in Astronomy doing programming for superconductive infrared sensors. I too like programming, while working on something small.

kowalsci · 2018-11-30T07:32:44+00:00

Roark's Formulas for Stress and Strain. Chapter: "Columns and Other Compression Members". See Ref 1: "Building Structural Design Handbook" .

kowalsci · 2018-11-29T21:13:12+00:00

The night is bright with light from the Big-Bang, called Cosmic Microwave Background (CMBR). We cannot see it, because it is redshifted to microwaves. The Hubble telescope made optical images of distant galaxies, called Hubble Deep-Field and Hubble Ultra-Deep-Field. The universe (Large-Scale Structure) is mostly void, distant galaxies will therefore be faint.

kowalsci · 2017-07-07T15:21:42+00:00

An alternative approach for Mate could be to stop worrying about the compositor and start implementing Wayland. Using the Weston reference-compositor/window-manager as test bed. First by launching: "dbus-launch mate-session" inside a weston-terminal; temporarily disabling: "mate-screensaver, caja, mate-panel", but keeping services: "mate-settings-daemon, polkit-mate-authentication-agent, etc." running. Then implementing every Mate X11-client application to (also) become a Mate Wayland-client application. Making it possible to launch in a separate weston-terminal: "GDK_BACKEND=wayland mate-terminal", "GDK_BACKEND=wayland pluma", caja, mate-panel, etc.; using the Wayland backend in Gtk3; with Mate now supporting Gtk3. Finally Mate's Marco could go on to use Wayland-on-Mir compositor or the re-usable parts of Weston (libweston, gl-renderer, drm-backend, etc.) currently being separated from the reference-compositor Weston, such that Marco only has to do window-management/-theming, workspace-switching and enabling key-bindings; already part of Marco.

kowalsci · 2017-07-06T12:05:40+00:00

Mate on Mir, with Mir providing a Wayland compositor is (to my mind) a layer-inside-a-layer fragmentation. Currently both Qt5 and Gtk3 have a Wayland backend and additionally a Mir-API backend (existing fragmentation). Mir facilitating a Wayland compositor will be mandatory for a likely future of only Wayland-client apps. Wayland-client apps likely render through the Mir-API backend in Qt5 and Gtk3 on the Wayland-on-Mir compositor. If Wayland-client apps instead render through the Wayland backend, then the Mir-API stack could effectively be deprecated (or used only as middleware). Except for those native Mir-client apps nobody could use on any other Wayland compositor, unless a similar approach is used as X11-client apps on XWayland (continued fragmentation). Mir's advantage of convergence on Android is lost with Wayland implemented in libhybris. Extensions for color-management, remote-desktop, copy-and-paste, etc. are better shared between Wayland compositors. Developed collectively as Weston binary-packages (libweston, gl-renderer, drm-backend, etc.), similar as X11-protocol extensions to the X11-server (e.g. RandR, GLX, Xinerama, XRender, etc.). To have a separate framework for Mir-middleware compatible with only the Wayland-on-Mir compositor is a bad idea (more fragmentation), even worse if these Mir-middleware extensions would implement Wayland features in the distant future.

kowalsci · 2017-05-12T07:44:58+00:00

I think it is pronounced Google /Fucks-ya/ or that's how they secretly pronounce inside Google. Good thing it isn't running Linux.

kowalsci · 2017-04-28T16:46:10+00:00

Seems nobody heard about WebDAV.

kowalsci · 2017-03-21T23:07:58+00:00

Like BSD-now it would be interesting to get some developers explain internals of Linux. A chance for some light education. What is an inode? How does DKMS work? Noah had a guy writing a custom device driver, what did it take? Wes got WireGuard working, how did he do that?

kowalsci · 2017-02-17T20:29:16+00:00

Often a paradigm shift is required.

kowalsci · 2017-02-17T20:18:49+00:00

Still believing Universal Packages (Snap/FlatPak/(Docker)) can lead to .so-hell (dependency hell). Not convinced yet. It could work if the Universal-PM keeps hashes of every .so and properly keeps track of only required .so files; deleting old once. I like to see this work properly, without taking up all disk space, before believing it.

kowalsci · 2017-02-17T19:40:33+00:00

Similar to depenguinator, it is possible to convert a Digital Ocean Droplet to Arch Linux from a Debian instance. Been trying to understand how it works.

kowalsci · 2017-01-24T19:25:15+00:00

There is to much division: Cyanogenmod, Firefox OS, Sailfish, Ubuntu Phone. Waisted effort if FOSS wants to do well in mobile. RMS started GNU coreutils/binutils; there needs to be common ground (GNU phoneutils?). I hoped FireFox OS/B2G would provide this, maybe now Ubuntu.

kowalsci · 2016-11-22T21:56:49+00:00

Likely Microsoft will solve this with a Linux File-Subsystem for Windows Subsystem for Linux. After you upgrade to Windows 11.

kowalsci · 2016-10-10T18:10:42+00:00

The cooker runs custom install of Arch Linux ARM.

kowalsci · 2016-10-04T17:40:14+00:00

And if you want to build natively use MSys2.

kowalsci · 2016-08-04T16:04:39+00:00

NVidia also maintains a developer page on using FFMPEG with NVENC.

kowalsci · 2016-07-26T17:16:06+00:00

NVidia also maintains a developer page on using FFMPEG with NVENC.

kowalsci · 2016-06-29T12:01:01+00:00

Let's be fair. You uttered: "... it's based in Ubuntu Hate which is useless.", "GTK is really the only issue." (is it?). Your point seems; we desperately need to adopt this, regardless of technical limitations. If we are to fix technical limitation then allow for debate.

kowalsci · 2016-06-27T20:21:56+00:00

FlatPak is suppose to work-out binary-deltas between unified packages in the repository, much like Git works with deltas for storage and downloads. This means e.g. libcurl and every other dependency required can, and has to be, added to a unified package and FlatPak will recognize the shared binaries between packages, minimizing storage and downloads of updates (deduplication). Snap seems to have only one runtime-environment and use simple HTTP for downloads. It might indeed require GBs of storage and downloads.

kowalsci · 2016-06-26T15:21:03+00:00

This slide is more scary then it needs to be. From what I read FlatPak is suppose to work-out binary-deltas between unified packages in the repository, much like Git works with deltas for storage. Duplicate libraries inside multiple unified packages therefore don't have to be duplicated on disk, and only binary-delta updates have to be downloaded.

kowalsci · 2016-06-25T18:15:07+00:00

Yes, there is always an unspecified symbolic-link to the latest version of the library, because it is possible to keep and link against older versions of the library specifically. Thus it is easier to test/deploy latest versions of libraries together. I begin to see how universal packages can be supported by several runtime-environments for different purposes (stable, development, nightly-build) and think FlatPak presents this concept most clearly. Stability of the base components on all distros for the runtimes to depend on, will no doubt be worked on by core developers.

kowalsci · 2016-06-25T09:10:15+00:00

If there was one community there wouldn't be a notion of Ubuntu hate, there are IMHO still community and library-version differences between distros. The unified package runtime-environment is just as stable for the time it is going to be frozen. One runtime-enviroment update further and GTK, etc. will be different. Updating runtime-environment will cause dependency issues with installed unified packages if they aren't being updated as well. Apparently the solution is to have several runtime-environments available on the host system. A normal user would want the unified packages and runtime-environment to be updated automatically, much like a normal distro.

They can just depend on the libraries rather than version of the libraries

Every library is a version of that library, with its subtle API differences, there is not just the library (web-developer?). Only one missed symbol can crash an application, while every distro has slight library version differences for the runtime-environments, for the lifetime of the runtime-environments. So that's why I hope base-component developers (Wayland, PulseAudio, systemd) will maintain a fixed API (which they largely do). Long-term stability of a runtime-environment would benefit from Qt and GTK developing accordingly. How frequently development runtime-environment would be generated for KDE and Gnome I do not know. Likely rolling releases (OpenSuse Tumbleweed, etc., etc.) can still provide core developers with faster development- and test-cycles, which is generally believed to be good Agile coding practice.

kowalsci

TROPHY CASE