rakudo-pkg v2: Github Actions/CloudSmith, devbuilds, Alpine repos, nfpm 2021-02-11
Posted by claudio in Uncategorized.Tags: packaging, raku, rakudo
1 comment so far
(In case you don’t know rakudo-pkg: it’s a project to provide native packages and relocatable builds of Rakudo for Linux distributions.)
The downward spiral of Travis since it was taken over by a Private Equity firm (there is a pattern here), triggered a long coming refactoring of the rakudo-pkg workflow. Until now the packages were created on Travis because it supported running Linux containers so we could tailor the build for each distribution/release. Almost at the same time JFrog announced it was sunsetting Bintray and other services popular with FOSS projects. The deb and rpm repos needed a new home.
Oh well, Travis and Bintray will be missed and certainly deserve our thanks for their service during years. It was difficult to imagine a better time to implement a few ideas from the good old TODO list.
From Travis to Github Actions
Github Actions is way faster than the post-P.E. Travis. Builds that took a few hours (we build around 25 distro/version combinations) now are done between 10 and 20 minutes. Not surprisingly this not only meant learning a complete new tool, but also a complete rewrite of the rakudo-pkg workflow.
Running on Github also means that every Github user can fork the repo including the rakudo-pkg Github workflows. One of the advantages of a rewrite is implementing new functionalities, like the new feature of rakudo-pkg to allow everyone to test the upstream MoarVM/NQP/Rakudo and zef commits/releases:
From Bintray to CloudSmith with Alpine repositories
Cloudsmith has a huge advantage over Bintray: it supports Alpine Linux repositories, making it a great addition to the rpm and deb repositories we already offer. The packages in the old repositories were GPG signed by BinTray. From now onwards, rakudo-pkg will be signed with his own key on Cloudsmith. Check the project’s README for instructions how to change your configuration. So far the experience with CloudSmith has been stellar. Their support is impressively responsive and they solve issues immediately, sometime while we were chatting about it.
From fpm to nfpm
rakudo-pkg created packages with the venerable fpm, written in Ruby. While the tool is extremely capable, I spent most of the time of a release getting fpm to build on new versions of distributions. The Ruby Gems ecosystem looks like a moving target. Enter nfpm, inspired with fpm but with the promise of a single binary. Written it Go, it’s more accessible to me to understand how it works and send fixes upstream if needed. The devs are also very responsive and fixed one issue I encountered extremely fast.
Feel free to open issues of send PRs if I missed something or if you have ideas to improve rakudo-pkg
Quo vadis, Perl? 2018-11-08
Posted by claudio in Uncategorized.Tags: community, foss, Perl, perl 6, raku
comments closed
We’ve had a week of heated discussion within the Perl 6 community. It is the type of debate where everyone seems to lose. It is not the first time we do this and it certainly won’t be the last. It seems to me that we have one of those about every six months. I decided not to link to many reiterations of the debate in order not to feed the fire.
Before defining sides in the discussion it is important to identify the problems that drives the fears and hopes of the community. I don’t think that the latest round of discussions was about the Perl 6 alias in itself (Raku), but rather about the best strategy to answer to two underlying problems:
- Perl 5 is steadily losing popularity.
- Perl 6, despite the many enhancements and a steady growth, is not yet a popular language and does not seem to have a niche or killer app in sight yet to spur rapid adoption.
These are my observations and I don’t present them as facts set in stone. However, to me, they are the two elephants in the room. As an indication we could refer to the likes of TIOBE where Perl 5 fell off the top 10 in just 5 years (from 8th to 16th, see “Very Long Time History” at the bottom) or compare Github stars and Reddit subscribers of Perl 5 and 6 with languages on the same level of popularity on TIOBE.
Perl 5 is not really active on Github and the code mirror there has until today only 378 stars. Rakudo, developed on Github, has understandably more: 1022. On Reddit 11726 people subscribe to Perl threads (mostly Perl 5) and only 1367 to Perl 6. By comparison, Go has 48970 stars on Github and 57536 subscribers on Reddit. CPython, Python’s main implementation, has 20724 stars on Github and 290 308 Reddit subscribers. Or put differently: If you don’t work in a Perl shop, can you remember when a young colleague knew about Perl 5 besides by reputation? Have you met people in the wild that code in Perl 6?
Maybe this isn’t your experience or maybe you don’t care about popularity and adoption. If this is the case, you probably shrugged at the discussions, frowned at the personal attacks and just continued hacking. You plan to reopen IRC/Twitter/Facebook/Reddit when the dust settles. Or you may have lost your patience and moved on to a more popular language. If this is the case, this post is not for you.
I am under the impression that the participants of what I would call “cyclical discussions” *do* agree with the evaluation of the situation of Perl 5 and 6. What is discussed most of the time is clearly not a technical issue. The arguments reflect different –and in many cases opposing— strategies to alleviate the aforementioned problems. The strategies I can uncover are as follows:
Perl 5 and Perl 6 carry on as they have for longer than a decade and half
Out of inertia, this a status-quo view is what we’ve seen in practice today. While this vision honestly subscribes to the “sister languages narrative” (Perl is made up of two languages in order to explain the weird major version situation), it doesn’t address the perceived problems. It chooses to ignore them. The flip side is that with every real or perceived threat to the status-quo the debate resurges.
Perl 6 is the next major version of Perl
This is another status-quo view. The “sister languages narrative” is dead: Perl 6 is the next major version of Perl 5. While a lot of work is needed to make this happen, it’s work that is already happening: make Perl 6 fast. The target, however, is defined by Perl 5: It must be faster than the previous release. Perl consists of many layers and VMs are interchangeable: it’s culturally still Perl if you replace the Perl 5 runtime with one from of Perl 6. This view is not well received by many people in Perl 5 community, and certainly by those emotionally or professionally invested in “Perl”, with most of the time Perl meaning Perl 5.
Both Perl 5 and Perl 6 are qualified/renamed
This is a renaming view that looks for a compromise in both communities. The “sister languages narrative” is the real world experience and both languages can stand on their own feet while being one big community. By renaming both projects and keeping Perl in the name (e.g. Rakudo Perl, Pumpkin Perl) the investment in the Perl name is kept, while the next major version number dilemma is dissolved. However this strategy is not an answer for those in the Perl 6 community that experience that the (unjustified) reputation of Perl 5 is hurting Perl 6’s adoption. On the Perl 5’s side is some resentment why good old “Perl” needs to be renamed when Perl 6 is the newcomer.
Rename Perl 6
Perl 6’s adoption is hindered by Perl 5’s reputation and, at the same time, Perl 6’s major number “squatting” places Perl 5 in limbo. The “sister language narrative” is the real world situation: Perl 5 is not going away and it should not. The unjustified reputation of Perl 5 for some people is not something Perl 6 needs to fix. Only action of the Perl 6 community is required in the view. However, a “sisterly” rename will benefit Perl 5. Liberating the next major version will not fix Perl 5’s decline, but it may be a small piece of the puzzle of the recovery. Renaming will result in more loosely coupled communities, but Perl communities are not mutually exclusive and the relation may improve without the version dilemma. The “sister language narrative” becomes a proud origin story. Mostly Perl 6 people heavily invested in the Perl *and* the Perl 6 brand opposed this strategy.
Alias Perl 6
While being very similar to the strategy above, this view is less ambitious as it only cares about Perl 6’s adoption is hindered by Perl 5’s reputation. It’s up to Perl 5 to fix their major version problem. It’s a compromise between (a number of) people in the Perl 6 community. It may or may not be a way to proof if an alias catches on, the renaming of Perl 6 should stay on the table.
–
Every single strategy will result in people being angry or disappointed because they honestly believe it hurts the strategy that they feel is necessary to alleviate Perl’s problems. We need to acknowledge that the fears and hopes are genuine and often related. Without going in detail to not reignite the fire (again), the tone of many of the arguments I heard this week from people opposing the Raku alias rung very close to me to the arguments Perl 5 users have against the Perl 6 name. Being a victim of injustice by people that don’t care for an investment of years and a feeling of not being listen to.
By losing the sight of the strategies in play, I feel the discussion degenerated very early in personal accusations that certainly leave scars while not resulting in even a hint of progress. We are not unique in this situation, see the recent example of the toll it took on Guido van Rossum. I can only sympathize with Larry is feeling these days.
While the heated debates may continue for years to come, it’s important to keep an eye on people that silently leave. The way to irrelevance is a choice.
(I disabled comments on this entry, feel free to discuss it on Reddit or the like. However respect the tone of this message and refrain from personal attacks.)
Post-it: how to switch to the discrete nvidia card on Ubuntu 18.04 2018-05-03
Posted by claudio in Uncategorized.Tags: driver, fix, nvidia, post-it, Ubuntu
add a comment
Another post-it note so I don’t forget (the first one is about how to purge the nvidia drivers and use the open source drivers).
The nvidia drivers are often problematic, and as long the open source drivers have decent performance, that’s OK. On laptops you can always switch to the Intel card with prime, using but in fact bypassing the nvidia drivers.This is also how the open source nouveau driver work.
However, since a few Ubuntu releases the Nvidia drivers seem more buggy, on one one of my system I see this out of the box behaviour:
- With the open source nouveau drivers the performance on Xorg is terrible (choppy video, OK desktop). Xorg is the default graphical server on Ubuntu 18.04. On 17.10 the default was Wayland.
- With the open source nouveau drivers the performance on Wayland is good (e.g. for 1080p HEVC video).
- With the closed source nvidia driver set to use the intel driver the performance on Xorg and Wayland is terrible (choppy video, OK desktop).
- With the closed source nvidia driver set to use the nvidia you’re stuck in a login manager loop, a black screen or terrible performance on Xorg and Wayland (choppy video, OK desktop).
If you’re ok with using Wayland (I am on the machine in question, at work my machine has Intel video and I am using Xorg), stick with nouveau and Wayland. Your laptop will get less hot (fans!) and have better battery life. Virtual consoles (ctrl+alt+) will still be available.
If you need Xorg, using the closed source nvidia driver is the only way to get good performance, at least on my machine. If you want to use this driver, follow the instructions below. Be sure to know what you do, you won’t loose files, but you may make your system unbootable (recover with an usb disk) if not done correctly:
– Make sure nvidia is not blacklisted, remove bumblebee if installed. Have a look in /etc/modules and /etc/modprobe.d/*:
$ sudo apt-get remove --purge bumblebee
$ grep nvidia /etc/modules /etc/modprobe.d/*
“blacklist nvidia” is what’s mostly used, remove that.
– Add “nvidia-drm.modeset=1” to the GRUB_CMDLINE line in /etc/default/grub:
$ sudo vi /etc/default/grub
(or use nano instead of vi)
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
becomes
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvidia-drm.modeset=1"
– Activate the changes:
$ sudo update-grub
– Install Nvidia drivers:
$ sudo ubuntu-drivers autoinstall
– Check if prime has nvidia selected, select nvidia otherwise:
$ prime-select query
$ sudo prime-select nvidia
5. Reboot
$ sudo init 6
Be warned that modeset=1 disables the virtual consoles (ctl+alt+<nr>).
That’s it.
Ubuntu 17.10 + Gnome: some hidden configurations 2017-10-21
Posted by claudio in Uncategorized.Tags: better-defaults-needed-department, dconf, gnome, Gnome3, Ubuntu, Ubuntu 17.10
10 comments
Update 20180216: remark about non-Ubuntu extensions & stability.
I like what the Ubuntu people did when adopting Gnome as the new Desktop after the dismissal of Unity. When the change was announced some months ago, I decided to move to Gnome and see if I liked it. I did.
It’s a good idea to benefit of the small changes Ubuntu did to Gnome 3. Forking dash-to-dock was a great idea so untested updates (e.g. upstream) don’t break the desktop. I won’t discuss settings you can change through the “Settings” application (Ubuntu Dock settings) or through “Tweaks”:
$ sudo apt-get install gnome-tweak-tool
It’s a good idea, though, to remove third party extensions so you are sure you’re using the ones provided and adapted by Ubuntu. You can always add new extensions later (the most important ones are even packaged).
$ rm -rf ~/.local/share/gnome-shell/extensions/*
Working with Gnome 3, and in less extent with MacOS, taught me that I prefer bars and docks to autohide. I never did in the past, but I feel that Gnome (and MacOS) got this right. I certainly don’t like the full height dock: make it so small as needed. You can use the graphical “dconf Editor” tool to make the changes, but I prefer the safer command line (you won’t make a change by accident).
To prevent Ubuntu Dock to take all the vertical space (i.e., most of it is just an empty bar):
$ dconf write /org/gnome/shell/extensions/dash-to-dock/extend-height false
A neat Dock trick: when hovering over a icon on the dock, cycle through windows of the application while scrolling (or using two fingers). Way faster than click + select:
$ dconf write /org/gnome/shell/extensions/dash-to-dock/scroll-action "'cycle-windows'"
I set the dock to autohide in the regular “Settings” application. An extension is needed to do the same for the Top Bar (you need to log out, and the enable it through the “Tweaks” application):
$ sudo apt-get install gnome-shell-extension-autohidetopbar
Update: I don’t install extensions any more besides the ones forked by Ubuntu. In my experience, they make the desktop unstable under Wayland. That’s said, I haven’t seen crashes related to autohidetopbar. That said, I moved back to Xorg (option at login screen) because Wayland feels less stable. The next Ubuntu release (18.04) will default to Xorg as well meaning that at least until 18.10 Wayland won’t be the default session.
Oh, just to be safe (e.g., in case you broke something), you can reset all the gnome settings with:
$ dconf reset -f /
Have a look at the comments for some extra settings (that I personally do not use, but many do).
Some options that I don’t use far people have asked me about (here and elsewhere)
Specially with the setting that allows scrolling above, you may want to only switch between windows of the same application in the active workspace. You can isolate workspaces with:
$ dconf write /org/gnome/shell/extensions/dash-to-dock/isolate-workspaces true
Hide the dock all the time, instead of only when needed. You can do this by disabling “intellihide”:
$ dconf write /org/gnome/shell/extensions/dash-to-dock/intellihide false
Post-It: enable mobile hotspot on Mobile Vikings (BE) 2017-07-25
Posted by claudio in Uncategorized.Tags: hotspot, mobile, mobile vikings, post-it
add a comment
Yesterday, it was the second time I wondered why the hotspot of my MotoG5 phone wasn’t working with my tablet (after an OS update on the phone and the tablet).
The tablet connected fine to the phone hotspot through wifi, but the traffic was not routed to the Internet. I forgot about the first time I debugged the problem, so a little post-it not to forget it again. The secret is to change the APN type to:
APN type: supl,default
As reference, the other settings for Mobile Vikings:
APN: web.be Username: web Password: web MCC: 206 MNC: 20 Authentication Type: PAP
So, what about (Perl 6) dependencies? 2017-05-28
Posted by claudio in Uncategorized.Tags: cpan, deployment, golang, Perl, perl6
9 comments
When I need to program something, most of the time I use Perl 5, Go or Perl 6. Which one depends on the existence and maturity of libraries and the deployment strategy (and I must admit, probably my mood). Most applications I write at work are not that big, but they need to be stable and secure. Some end up in production as an extension or addition to the software that is the core of our authentication and authorisation infrastructure. Some programs are managed by other teams, e.g. of sysadmin-type applications like the monitoring of a complex chain of microservices. Finally, proof of concept code is often needed when designing a new architecture. I believe that If your software is cumbersome/fragile to install and maintain, people won’t use it. Or worse, stick with an old version.
Hence, I like CPAN. A lot. I love how easy it is to download, build, test and install Perl 5 libraries. cpanminus made the process even more zero-conf. When not using Docker, tools like App::Fatpacker and Carton can bundle libraries and you end with a mostly self-contained application (thx mst and miyagawa).
Go, a compiled language, took a different path and opted for static binaries. The included (Go) libraries are not downloaded and built when you’re deploying, but when you’re developing. Although this is a huge advantage, I am not too fond of the dependency system: you mostly end up downloading random versions from the master branch of random Github repos (the workaround is using external webservices like gopkg.in, not ideal). The only sane way is to “vendor in” (also with a tool) your dependencies pretty much the same way Carton does: you copy the libs in your repository (but still without versioning). I hear the Go community is working at this, but so far there are only workarounds.
In the Perl 6 world, the zef module manager does provide a kind of cpanminus-like experience. However, in contrast with cpanminus it does this by downloading code from a zillion Github repo’s where the versioning is questionable. The is no clear link between the version fixed in the metadata (META6.json) and branches/tags on the repo. Like mentioned above, Go gets away with this due to static compiling, although the price is high: your projects will have dozens of versions of the same lib, probably even with a different API… and no way to declare the version in the code.
The centralised Perl 5 approach approach is fairly complex. It works because of the maturity of the ecosystem (the “big” modules are pretty stable) and the taken-for-granted testing culture (thank you toolchain and testing people!). Actually, in my opinion, the only projects that really solved the dependency management problem are the Linux & BSD distributions by boxing progress in long release cycles. Developers want the last shiny lib, so that won’t work.
The Perl 6 devs have no static compiling on the agenda, so it’s clear that the random Github repo situation is far from ideal. That’s why I was pretty excited to read on #perl6 that Perl 6 code can now be uploaded to CPAN (with Shoichi Kaji’s mi6) and installed (with Nick Logan’s zef). Today, the Perl 6 ecosystem has neither the maturity of the one of Perl 5 nor its testing culture. The dependency chain can be pretty fragile at times. Working within a central repository with an extensive and mature testing infrastructure will certainly help over time. One place to look for libraries, rate them, find the documentation, and so on. Look at their state and the state of its dependencies. This is huge. But I don’t think that CPAN will fix the problems of a young ecosystem right away. I think there is an opportunity here to build on the shoulders on CPAN, while keeping the advantages of a new language: find out what works.
Personally, I would love to have a built-in packaging solution like Carton –or even App::Fatpacker– out of the box. I think there is something to be said for the “vendoring-in” of the dependencies in the application repo (putting all the dependencies in a directory in the repo). The Perl 6 language/compiler has advantages over Perl 5. You can specify the compiler you target so your code doesn’t break when your compiler (also) targets a more recent milestone (allowing the core devs to advance by breaking stuff). Soon, you’ll be able to You can even load different versions of the same library in the same program (thx for the correction, nine).
The same tool could even vendor (and update) different version of the same library. At “package time” this tool would look at your sources and include only the versions of the libraries that are referenced. The result could be a tar or a directory with everything needed to run your application. As a bonus point, it would be nice to still support random repos for libraries-in-progress or for authors that opted not to use CPAN.
My use case is not everyone’s, so I wonder what people would like to see based on their experience or expectations. I think that now, with the possibility of a CPAN migration, it a good time to think about this. Let’s gather ideas. The implementation is for later :).
Post-it: how to revive X on Ubuntu after nvidia kills it 2017-04-12
Posted by claudio in Uncategorized.Tags: driver, fix, nvidia, post-it, Ubuntu
add a comment
20180503: Updated for Ubuntu 18.04
I am not a hug fan of the Linux Nvidia drivers*, but once in a while I try them to check the performance of the machine. More often than not, I end up in a console and no X/Wayland.
I have seen some Ubuntu users reinstalling their machine after this f* up, so here my notes to fix it (I always forget the initramfs step and end up wasting a lot of time):
$ sudo apt-get remove --purge nvidia-*
If /etc/X11/xorg.conf is present (often not the case in Ubuntu 18.04), backup it:
$ sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf_pre-nvidia
On recent releases, this step is not longer necessary because it’s automatically triggered by step 1:
$ sudo update-initramfs -u
Reboot the computer:
$ reboot
*: I am not a fan of the Windows drivers either now that Nvidia decided to harvest emails and track you if you want updates.
Notes from my Unity -> Gnome3 migration 2017-04-07
Posted by claudio in Uncategorized.Tags: gnome, Gnome3, Linux, Linux Desktop, Thanks for all the fish, Ubuntu, unity
4 comments
Updated: 20170419: gnome-shell extension browser integration.
Updated: 20170420: natural scrolling on X instead of Wayland.
Updated: 20170512: better support for multi monitor setups.
Updated: 20170525: add “No TopLeft Hot Corner”, use upstream “Top Icons Plus” instead of the one in the repos.
Introduction
Mark Shuttleworth, founder of Ubuntu and Canonical, dropped a bombshell: Ubuntu drops Unity 8 and –by extension– also the Mir graphical server on the desktop. Starting from the 18.04 release, Ubuntu will use Gnome 3 as the default Desktop environment.
Sadly, the desktop environment used by millions of Ubuntu users –Unity 7– has no path forward now. Unity 7 runs on the X.org graphical stack, while the Linux world –including Ubuntu now– is slowly but surely moving to Wayland (it will be the default on Ubuntu 18.04 LTS). It’s clear that Unity has its detractors, and it’s true that the first releases (6 years ago!) were limited and buggy. However, today, Unity 7 is a beautiful and functional desktop environment. I happily use it at home and at work.
Soon-to-be-dead code is dead code, so even as a happy user I don’t see the interest in staying with Unity. I prefer to make the jump now instead of sticking a year with a desktop on life support. Among other environments, I have been a full time user of CDE, Window Maker, Gnome 1.*, KDE 2.*, Java Desktop System, OpenSolaris Desktop, LXDE and XFCE. I’ll survive :).
The idea of these lines is to collect changes I felt I needed to make to a vanilla Ubuntu Gnome 3 setup to make it work for me. I made the jump 1 week before the release of 17.04, so I’ll stick with 17.04 and skip the 16.10 instructions (in short: you’ll need to install gnome-shell-extension-dashtodock from an external source instead of the Ubuntu repos).
The easiest way to make the use Gnome on Ubuntu is, of course, installing the Ubuntu Gnome distribution. If you’re upgrading, you can do it manually. In case you want to remove Unity and install Gnome at the same time:
$ sudo apt-get remove --purge ubuntu-desktop lightdm && sudo apt-get install ubuntu-gnome-desktop && apt-get remove --purge $(dpkg -l |grep -i unity |awk '{print $2}') && sudo apt-get autoremove -y
Changes
Add Extensions:
- Install Gnome 3 extensions to customize the desktop experience:
$ sudo apt-get install -y gnome-tweak-tool gnome-shell-extension-dashtodock gnome-shell-extension-better-volume gnome-shell-extension-refreshwifi gnome-shell-extension-disconnect-wifi
- Install the gnome-shell integration (the one on the main Ubuntu repos does not work):
$ sudo add-apt-repository ppa:ne0sight/chrome-gnome-shell && sudo apt-get update && sudo apt-get install chrome-gnome-shell - Install the “Multi-monitor add-on“, the “Top Icon Plus” (we use an upstream version op the previous two extensension because the ones on the Ubuntu repos are buggy), the “Not Topleft Hot Corner” (a must in a multi-monitor setup) and the “Refresh wifi” extensions. You’ll need to install a browser plugin. Refresh the page after installing the plugin.
- Log off in order to activate the extensions.
- Start gnome-tweak-tool and enable “Better volume indicator” (scroll wheel to change volume), “Dash to dock” (a more Unity-like Dock, configurable. I set the “Icon size limit” to 24 and “Behavior-Click Action” to “minimize”), “Disconnect wifi” (allow disconnection of network without setting Wifi to off), “Refresh Wifi connections” (auto refresh wifi list), “Multi monitors add-on” (add a top bar to other monitors) and “Topicons plus” (put non-Gnome icons like Dropbox and pidgin on the top menu).
Change window size and buttons:
- On the Windows tab, I enabled the Maximise and Minise Titlebar Buttons.
- Make the window top bars smaller if you wish. Just create ~/.config/gtk-3.0/gtk.css with these lines:
/* From: http://blog.samalik.com/make-your-gnome-title-bar-smaller-fedora-24-update/ */
window.ssd headerbar.titlebar {
padding-top: 4px;
padding-bottom: 4px;
min-height: 0;
}
window.ssd headerbar.titlebar button.titlebutton {
padding: 0px;
min-height: 0;
min-width: 0;
}
Disable “natural scrolling” for mouse wheel:
While I like “natural scrolling” with the touchpad (enable it in the mouse preferences), I don’t like it on the mouse wheel. To disable it only on the mouse:
$ gsettings set org.gnome.desktop.peripherals.mouse natural-scroll false
If you run Gnome on good old X instead of Wayland (e.g. for driver support of more stability while Wayland matures), you need to use libinput instead of the synaptic driver to make “natural scrolling” possible:
$ sudo mkdir -p /etc/X11/xorg.conf.d && sudo cp -rp /usr/share/X11/xorg.conf.d/40-libinput.conf /etc/X11/xorg.conf.d/
Log out.
Enable Thunderbird notifications:
For Thunderbird new mail notification I installed the gnotifier Thunderbird add-on: https://addons.mozilla.org/en-us/thunderbird/addon/gnotifier/
Extensions that I tried, liked but ended not using:
- gnome-shell-extension-pixelsaver: it feels unnatural on a 3 screen setup like I use at work, e.g. min-max-close windows buttons on the main screen for windows on other screens..
- gnome-shell-extension-hide-activities: the top menu is already mostly empty, so it’s not saving much.
- gnome-shell-extension-move-clock: although I prefer the clock on the right, the default middle position makes sense as it integrates with notifications.
That’s it (so far 🙂 ).
Thx to @sil, @adsamalik and Jonathan Carter.
Intel NUC 5CPYH and Ubuntu 16.04 2016-09-22
Posted by claudio in Uncategorized.Tags: "home server", Linux, nuc, Ubuntu
add a comment
I decided to move my home backup drives to ZFS because I wanted built-in file checksumming as a prevention against silent data corruption. I chose ZFS over BrtFS because I have considerable experience with ZFS on Solaris.
I knew that ZFS loves RAM, hence I upgraded my home “server” (NFS/Samba/Docker) from an old laptop with 2GB of RAM to the cheapest Intel NUC I could find with USB3, Gigabit ethernet and 8GB of RAM. The C5CPYH model fitted the bill.
Two remarks for those that want to install Linux on this barebones mini-pc:
- Update the BIOS first, otherwise the Ubuntu 16.04 server USB installer won’t start. My model had a very recent BIOS version, but still I needed the latest. BIOS updates can be found here. (There is also an option to select Linux as the OS in the BIOS.)
- Ubuntu 16.04 server did not find the network card at install time (missing Realtek drivers). Just finish the installation. Once rebooted, the correct driver for the network card will be already loaded. Just finish the IP configuration in /etc/network/interfaces.
rakudo-pkg: Create OS packages for Rakudo Perl 6 using Docker 2016-09-05
Posted by claudio in Uncategorized.Tags: deb, Perl, perl6, pkg, rakudo, rpm
1 comment so far
There was an interesting discussion on #perl6 (irc.freenode.net) about the use of rakudobrew as a way for end-users to install Rakudo Perl 6 (see how-to-get-rakudo).
rakudobrew, inspired by perlbrew, is a way to manage (and compile) different versions of rakudo. nine argued that it’s primarily meant as a tool for rakudo developers. Because of the increased complexity (e.g. when dealing with modules) it’s not targeted at end-users. While being a big fan of rakudobrew, I agree with nine.
The problem is that there are no Linux binaries on the download page (there are for MacOS and Windows), so users are stuck with building from source (it can be fun, but after a while it isn’t).
rakudo-pkg is a github project to help system administrators (and hopefully Rakudo release managers) to easily provide native Linux packages for end users. So far, I added support for creating Ubuntu 16.04 LTS amd64 and i386 packages and Centos 7 amd64. These are the systems I use the most. Feel free to add support for more distributions.
rakudo-pkg uses Docker. The use of containers means that there is no longer need for chasing dependencies and no risks of installing files all over your system. It also means that as long the building machine is a Linux 64-bit OS, you can build packages for *all* supported distributions.
Within the containers, rakudo-pkg uses fpm. The created packages are minimalistic by design: they don’t run any pre/post scripts and all the files are installed in /opt/rakudo. You’ll have to add /opt/rakudo/bin to your PATH. I also added two additional scripts to install Perl 6 module managers (both have similar functionalities):
install_panda_as_user.sh
install_zef_as_user.sh
If you just want to create native packages, just go to the bin directory and execute the run_pkgrakudo.pl command. In this case there is no need to locally build the Docker images: you’ll automatically retrieve the image from the rakudo namespace on Docker Hub. Of course, if you want to create the container images locally, you can use the supplied dockerfiles in the docker directory. Have a look at the README.md for more information.
You can find examples of packages created with rakudo-pkg here (they need to be moved to a more definitive URL).
Have fun.
