Roger Luedecke
posted at
Netflix arrives to openSUSE without dirty tricks, yes natively.
Naturally, if it were so simple one would not need an article. There has been a lot of news floating around about +Netflix finally being available natively for +Linux. In case you are not aware, getting Netflix on Linux was a labored and complicated process requiring all sorts of WINE hacking or virtualization. +Microsoft had announced that its strategy would be changing away from Silverlight which Netflix has depended on for their DRM content delivery. Netflix then announced they would be dropping Silverlight in favor of +HTML5 once some DRM framework was developed so they could secure their licensed content. Naturally this announcement was greeted with excitement from Linux desktop users all over, excepting of course those whom are absolutely opposed to DRM.
In the last couple of days, there has been a flurry of articles and tutorials on how to get Netflix to work natively. Most of these of course are claiming that it is +Ubuntu only, though this is absolutely false. The new HTML5 DRM video delivery is enabled by Network Security Services which have been around for a long time, but have only recently acquired the Encrypted Media Extensions for the sort of secured DRM necessary for Netflix. While +Android and Chrome OS had Netflix, this left people wondering why not desktop Linux since the two other operating systems use the Linux kernel too. On Chrome, Google developed a special plugin to provide the DRM to allow Netflix to work, while on Android this was facilitated by an app that had the DRM built in.
So now we have working DRM thanks to Google, Mozilla, and many other parties. Firstly, you need NSS 3.16.2 or greater and the +Google Chrome browser version 37 or higher. You will need to go into your Netflix settings and tell it you'd prefer the HTML5 player. Upto very recently you'd need to have your browser falsely identify itself as another browser to get it to work, but this is no longer necessary. At present Chromium and Firefox cannot run Netflix. +Mozilla Firefox will be getting support as well, but it'll be reliant on a proprietary Content Decryption Module or CDM from +Adobe beyond their more conservative approach with a greater focus on privacy and security. This module would most likely be delivered in the same fashion as the +Adobe Flash Player.
In the last couple of days, there has been a flurry of articles and tutorials on how to get Netflix to work natively. Most of these of course are claiming that it is +Ubuntu only, though this is absolutely false. The new HTML5 DRM video delivery is enabled by Network Security Services which have been around for a long time, but have only recently acquired the Encrypted Media Extensions for the sort of secured DRM necessary for Netflix. While +Android and Chrome OS had Netflix, this left people wondering why not desktop Linux since the two other operating systems use the Linux kernel too. On Chrome, Google developed a special plugin to provide the DRM to allow Netflix to work, while on Android this was facilitated by an app that had the DRM built in.
So now we have working DRM thanks to Google, Mozilla, and many other parties. Firstly, you need NSS 3.16.2 or greater and the +Google Chrome browser version 37 or higher. You will need to go into your Netflix settings and tell it you'd prefer the HTML5 player. Upto very recently you'd need to have your browser falsely identify itself as another browser to get it to work, but this is no longer necessary. At present Chromium and Firefox cannot run Netflix. +Mozilla Firefox will be getting support as well, but it'll be reliant on a proprietary Content Decryption Module or CDM from +Adobe beyond their more conservative approach with a greater focus on privacy and security. This module would most likely be delivered in the same fashion as the +Adobe Flash Player.
Josef Reidinger
posted at
Ruby: Do not use += in loops
Hi,
My motivation for writing this blog post is to have one simple place where I can point everybody using += in a loop. I will describe here why it can kill the performance of any application or library and will also show some measurement to demonstrate it.
Let’s start with practical measurement. I created a simple measurement script which looks like this:
require "benchmark"
N = 100000
Benchmark.bm(15) do |x|
x.report("Array#+=") do
arr = []
N.times { arr += [1] }
end
x.report("Array#concat") do
arr = []
N.times { arr.concat [1] }
end
x.report("String#+=") do
s = ""
N.times { s += "1" }
end
x.report("String#<<") do
s = ""
N.times { s << "1" }
end
end
And result for N = 10 000 looks like this:
user system total real
Array#+= 0.280000 0.020000 0.300000 ( 0.302993)
Array#concat 0.000000 0.000000 0.000000 ( 0.002291)
String#+= 0.040000 0.000000 0.040000 ( 0.041442)
String#<< 0.000000 0.000000 0.000000 ( 0.002437)
and for N = 100 000 looks like this:
user system total real
Array#+= 31.410000 6.940000 38.350000 ( 38.635201)
Array#concat 0.030000 0.000000 0.030000 ( 0.028933)
String#+= 3.590000 0.020000 3.610000 ( 3.635690)
String#<< 0.030000 0.000000 0.030000 ( 0.029524)
As can be seen, it does not raise in a linear way and now it is time for some theory to explain why.
When you push elements to the same object, the complexity class of the loop is O(n), since it grows in a linear way. For += it needs to create a copy of the array or string first and then append the new part. The copy complexity class is also O(n) as it depends on array size (the approximation would be O(n/2), which means an O(n) complexity class because half is constant). Copy optimization mechanisms can help, but the complexity class will remain the same. The result is that you need to perform n times the copy operation, which is O(n). So += complexity class is O(n^2). That explains why the times do not raise linearly but quadratically.
Therefore, += should never, ever, be used in loops. If you need to have a new object, then create an empty Array or String before the loop and push new elements into it. It is more efficient. Sure Ruby is not your tool if you are looking for a way to reduce every millisecond, but there is no excuse to use the worse algorithm as it can make application unusable performance-wise.
Roger Luedecke
posted at
Sneak peek at openSUSE 13.2; hands on with beta 1
I've been running the beta 1 of 13.2 for a few days now, and there are lots of interesting and welcome changes. Overall it is surprisingly bug free, and I anticipate it will be a very smooth release (at least on +GNOME since I don't use KDE). Now, if you want to know what versions of packages are included you may take a look at this post. I on the other hand want to introduce you to the things that you may NOT know, and that are particularly interesting.
So we have long heard that btrfs would be replacing EXT4 as the default file-system in +openSUSE and many other distributions eventually. Generally it is ready and eventually will outstrip EXT4 and other file-systems for speed as well as it's many other compelling features. However as of yet it still suffers from being a bit too slow. Thus, if you use a separate /home partition you'll notice XFS is being proposed as the default. For some of you this makes sense, but if you are like me it came as quite a surprise. Last I knew XFS was recommended for ridiculously huge volumes and suffered performance issues that made it impractical for domestic use. Naturally I wanted to get to the bottom of this. +Greg Freemyer offered the following explanation:
Now as you may know, YaST was recently rewritten in the Ruby language. A big reason for this is that only about two people at SUSE knew the language it was written in before called the YaST Markup Language or YML. This of course made it difficult to maintain, and even harder to get community contributions for. Thankfully this has worked out and we've been seeing lots of work on YaST, cleaning up code and modernizing it; adding stability and speed improvements across the entire suite. Our installer even is a YaST module and has seen improvements thanks to the switch to Ruby as well. The improvements are obvious with quick and responsive action across all of YaST. The installer has seen benefits of this as it is quicker, smoother, and more responsive than ever across any of the cards. A new card has been added allowing network configuration (no idea if it works with wifi at all since it isn't the NetworkManager) which among other things allows you to set the hostname for your computer. The interface itself has seen a nice facelift, now with a cleaner more readable experience. In the partitioning scheme card there is a simple modifier dialog that will allow you to set non-default file-systems as well as a check box for expanding SWAP to allow suspend. GRUB2 is now not only default, but the only supported bootloader and has seen bugfixes and obvious speed improvements. Also so far as installation is concerned this has become immensely faster, completing before I can even finish a cigarette. This improvement is due to streamlining the installation process; in the past it would make a large number of mkinitrd calls, whereas now it should only make one call at the very end of the process.
Overall this is turning out to be a very exciting release. And with as good as it looks in this early beta, I anticipate raving reviews. Please consider helping test this release, and file your bugs at our own Bugzilla.
So we have long heard that btrfs would be replacing EXT4 as the default file-system in +openSUSE and many other distributions eventually. Generally it is ready and eventually will outstrip EXT4 and other file-systems for speed as well as it's many other compelling features. However as of yet it still suffers from being a bit too slow. Thus, if you use a separate /home partition you'll notice XFS is being proposed as the default. For some of you this makes sense, but if you are like me it came as quite a surprise. Last I knew XFS was recommended for ridiculously huge volumes and suffered performance issues that made it impractical for domestic use. Naturally I wanted to get to the bottom of this. +Greg Freemyer offered the following explanation:
XFS was designed for high-end systems including supercomputers.The design is 20 years old, so many of the features it incorporates work well on current multi-core laptops and PCs.Though EXT4 is being developed still, it is too old to really cope with modern use cases. In benchmarks vs. XFS newer iterations of EXT4 were nearly able to catch up to the speed of modern XFS, but with one caveat; the journal had to be disabled, which as you probably know is a horrible idea leading to corruption and fragmentation of your data. For some further reading I suggest this article from +SUSE.
During the decade from 2000-2010, XFS had a well deserved reputation of working very inefficiently with small files. In the 2010/2011 timeframe XFS received major improvements related to metadata handling. This had a huge positive impact on how well XFS works with small files. The key concept is that journal is now maintained initially in RAM. Prior to streaming a large junk of journal information to the disk journal, it is now elevator sorted.
That means when the actual on disk updates are done by applying the journal, the disk head will follow a series of disk seeks all in the same direction. This drastically cut down on long disk head seeks when working applying the journal. The end result was drastically faster speeds when working with small files on rotating media.
ext4 on the other hand was designed for previous generation
computers. Although it can scale to the sizes needed today, it simply was not designed to handle that heavy workloads and massive scaling that modern laptops and desktops can demand. As such, ext4 is rapidly approaching end of life.
The envisioned replacement for ext4 for the last several years has been btrfs. Unfortunately, btrfs has not yet achieved the performance levels needed to take on heavy workloads.
Now as you may know, YaST was recently rewritten in the Ruby language. A big reason for this is that only about two people at SUSE knew the language it was written in before called the YaST Markup Language or YML. This of course made it difficult to maintain, and even harder to get community contributions for. Thankfully this has worked out and we've been seeing lots of work on YaST, cleaning up code and modernizing it; adding stability and speed improvements across the entire suite. Our installer even is a YaST module and has seen improvements thanks to the switch to Ruby as well. The improvements are obvious with quick and responsive action across all of YaST. The installer has seen benefits of this as it is quicker, smoother, and more responsive than ever across any of the cards. A new card has been added allowing network configuration (no idea if it works with wifi at all since it isn't the NetworkManager) which among other things allows you to set the hostname for your computer. The interface itself has seen a nice facelift, now with a cleaner more readable experience. In the partitioning scheme card there is a simple modifier dialog that will allow you to set non-default file-systems as well as a check box for expanding SWAP to allow suspend. GRUB2 is now not only default, but the only supported bootloader and has seen bugfixes and obvious speed improvements. Also so far as installation is concerned this has become immensely faster, completing before I can even finish a cigarette. This improvement is due to streamlining the installation process; in the past it would make a large number of mkinitrd calls, whereas now it should only make one call at the very end of the process.
Overall this is turning out to be a very exciting release. And with as good as it looks in this early beta, I anticipate raving reviews. Please consider helping test this release, and file your bugs at our own Bugzilla.
Alexander Naumov
posted at
Member
anaumovopenSUSE factory :: dumpe2fs
# dumpe2fs
dumpe2fs 1.42.12 (29-Aug-2014)
Segmentation fault
# echo $?
139
# dumpe2fs -h
dumpe2fs 1.42.12 (29-Aug-2014)
Segmentation fault
> rpm -qf `which dumpe2fs`
e2fsprogs-1.42.12-1.2.x86_64
> cat /etc/SuSE-release
openSUSE 20140909 (x86_64)
VERSION = 20140909
CODENAME = Harlequin
# /etc/SuSE-release is deprecated and will be removed in the future,
use /etc/os-release instead
# ltrace dumpe2fs
__libc_start_main([ "dumpe2fs" ]
setlocale(LC_MESSAGES, "") = "en_US.UTF-8"
setlocale(LC_CTYPE,"") = "en_US.UTF-8"
bindtextdomain("e2fsprogs", "/usr/share/locale") = "/usr/share/locale"
textdomain("e2fsprogs") = "e2fsprogs"
set_com_err_gettext(0x401a00, 1, 1, 0x73676f72707366) = 0
add_error_table(0x605260, 1, 1, 0x73676f72707366) = 0
__fprintf_chk(0x7f4fcb90f060, 1, 0x403b42, 0x403b3adumpe2fs 1.42.12 (29-Aug-2014)) = 31
getopt(1, 0x7fff9f754798, "bfhixVo:") = -1
ext2fs_open(0, 0x29000, 0, 0 < no return ...>
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
# strace dumpe2fs
execve("/sbin/dumpe2fs", ["dumpe2fs"], [/* 94 vars */]) = 0
brk(0) = 0x15c1000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc391daf000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=153158, ...}) = 0
mmap(NULL, 153158, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc391d89000
close(3) = 0
open("/lib64/libext2fs.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3>\1 \360"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=285064, ...}) = 0
mmap(NULL, 2380840, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc39194a000
mprotect(0x7fc39198d000, 2097152, PROT_NONE) = 0
mmap(0x7fc391b8d000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x43000) = 0x7fc391b8d000
close(3) = 0
open("/lib64/libcom_err.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3>\1 \27"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=14712, ...}) = 0
mmap(NULL, 2109960, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc391746000
mprotect(0x7fc391749000, 2093056, PROT_NONE) = 0
mmap(0x7fc391948000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x2000) = 0x7fc391948000
close(3) = 0
open("/lib64/libe2p.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3>\1`\""..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=32528, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc391d88000
mmap(NULL, 2128304, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc39153e000
mprotect(0x7fc391545000, 2093056, PROT_NONE) = 0
mmap(0x7fc391744000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x6000) = 0x7fc391744000
close(3) = 0
open("/usr/lib64/libuuid.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3>\1\340\26"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=19048, ...}) = 0
mmap(NULL, 2113928, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc391339000
mprotect(0x7fc39133c000, 2097152, PROT_NONE) = 0
mmap(0x7fc39153c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x3000) = 0x7fc39153c000
close(3) = 0
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3>\1\20\34\2"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1978611, ...}) = 0
mmap(NULL, 3832352, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc390f91000
mprotect(0x7fc39112f000, 2097152, PROT_NONE) = 0
mmap(0x7fc39132f000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x19e000) = 0x7fc39132f000
mmap(0x7fc391335000, 14880, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1,
0) = 0x7fc391335000
close(3) = 0
open("/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3>\1\20o"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=137435, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc391d87000
mmap(NULL, 2213008, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc390d74000
mprotect(0x7fc390d8c000, 2093056, PROT_NONE) = 0
mmap(0x7fc390f8b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x17000) = 0x7fc390f8b000
mmap(0x7fc390f8d000, 13456, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1,
0) = 0x7fc390f8d000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc391d86000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc391d84000
arch_prctl(ARCH_SET_FS, 0x7fc391d84780) = 0
mprotect(0x7fc39132f000, 16384, PROT_READ) = 0
mprotect(0x7fc390f8b000, 4096, PROT_READ) = 0
mprotect(0x7fc39153c000, 4096, PROT_READ) = 0
mprotect(0x7fc391744000, 4096, PROT_READ) = 0
mprotect(0x7fc391948000, 4096, PROT_READ) = 0
mprotect(0x7fc391b8d000, 4096, PROT_READ) = 0
mprotect(0x604000, 4096, PROT_READ) = 0
mprotect(0x7fc391db0000, 4096, PROT_READ) = 0
munmap(0x7fc391d89000, 153158) = 0
set_tid_address(0x7fc391d84a50) = 4002
set_robust_list(0x7fc391d84a60, 24) = 0
rt_sigaction(SIGRTMIN, {0x7fc390d7a9f0, [], SA_RESTORER|SA_SIGINFO, 0x7fc390d83890},
NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x7fc390d7aa80, [], SA_RESTORER|SA_RESTART|SA_SIGINFO,
0x7fc390d83890}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
brk(0) = 0x15c1000
brk(0x15e2000) = 0x15e2000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2434, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc391dae000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2434
read(3, "", 4096) = 0
close(3) = 0
munmap(0x7fc391dae000, 4096) = 0
open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES", O_RDONLY|O_CLOEXEC) = -1 ENOENT
(No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_MESSAGES", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
close(3) = 0
open("/usr/lib/locale/en_US.utf8/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=57, ...}) = 0
mmap(NULL, 57, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc391dae000
close(3) = 0
open("/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=26244, ...}) = 0
mmap(NULL, 26244, PROT_READ, MAP_SHARED, 3, 0) = 0x7fc391da7000
close(3) = 0
futex(0x7fc3913348f8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/usr/lib/locale/en_US.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT
(No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=256420, ...}) = 0
mmap(NULL, 256420, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc391d45000
close(3) = 0
write(2, "dumpe2fs 1.42.12 (29-Aug-2014)\n", 31dumpe2fs 1.42.12 (29-Aug-2014)
) = 31
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} ---
+++ killed by SIGSEGV +++
Segmentation fault
Wolfgang Rosenauer
posted at
openSUSE 11.4 has reached end of Evergreen support
I have posted the following to the openSUSE lists a few moments ago:
as you probably know our initial commitment to support 11.4 within Evergreen was until July 2014. http://en.opensuse.org/openSUSE:Evergreen While I was hoping that we can keep 11.4 alive for some time longer this is currently not possible from what I would call the "core team" which is Stefan and myself. We are too busy nowadays to be able to scan and patch every issue we get aware of. Thanks to you all who contributed to the success of Evergreen/11.4! The important message is: openSUSE 11.4 Evergreen is not actively maintained anymore! So if you can, we recommend to switch to openSUSE 13.1 as soon as possible which is still planned to be an Evergreen release. Some more details below: The repository already got and will most likely get more updates from package maintainers who care about 11.4 and/or their packages though. You noticed that with recent releases of patches for the bash and NSS issues already, BUT this is _no_ guarantee that every security issue will be fixed. We will accept contributions from anyone though and I will try to take care about "my" packages. Some numbers from 11.4 Evergreen (as far as I was able to get them easily): Evergreen lifetime: 21 months 11.4 overall lifetime (incl. Evergreen): 41 months / 3 years 5 months Evergreen lifetime numbers (w/o official maintenance period): Released update source packages: 804 Unique touched source packages: 177 rough number of patches (based on incident counter): 320 Let me also quote Marcus' numbers from official maintenance lifetime: Total updates: 723 Security: 416 Recommended: 306 Optional: 1
Lukas Ocilka
posted at
Yast Code Review Guide
All contributors and Yast team members are asked to use the very same simple rules for all code changes related to Yast, including Installer or just simply all code handled by thee Yast team, including, e.g., Linuxrc.
Please, see the guide here. We are looking forward your suggestions for improvements.
Stefan Seyfried
posted at
Building Yocto/Poky on openSUSE Factory
Since a few weeks, openSUSE Factory no longer is labeled as "openSUSE Project 13.2", but as:
UPDATE: Koen Kooi noted that "Yocto" is only the umbrella project and what I'm fixing here is actually the "poky" build system that's part of the project, so I edited this post for clarity. Thanks for the hint!
seife@susi:~> lsb_release -irWhen trying to build the current Yocto poky release, you get the following Warning:
Distributor ID: openSUSE project
Release: 20140918
WARNING: Host distribution "openSUSE-project-20140918" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.Now I know these warnings and have ignored those before. The list of tested distributions is hard coded in the build system configuration and in general it would be a bad idea to add not yet released versions (as 13.2) or rolling releases. And since the Factory release number changes every few days, it is clearly impossible to keep this up to date: once you have tested everything, the version has increased already. But apart from this, purely cosmetic warning, there is a really annoying consequence of the version change: the configuration cache of bitbake (the build tool used by Yocto poky/OpenEmbedded) is rebuilt on every change of the host distribution release. Updating the cache takes about 2 minutes on my machine, so doing a simple configuration check on your already built Yocto distribution once a week can get quite annoying. I looked for a solution and went for the "quick hack" route:
- bitbake parses "lsb_release -ir"
- I replace "lsb_release" with a script that emits filtered output and is before the original lsb_release in $PATH
This is what I have put into ~/bin/lsb_release (the variable check is a bit of paranoia to let this only have an effect in a bitbake environment):
#!/bin/bash
if [ -z "$BB_ENV_EXTRAWHITE" -o "x$1" != "x-ir" ]; then
exec lsb-release $@
fi
printf "Distributor ID:\topenSUSE project\nRelease:\t2014\n"
Then "chmod 755 ~/bin/lsb_release" and now the warning is
WARNING: Host distribution "openSUSE-project-2014" has not been validated...And more important: it stays the same after updating Factory to the next release. Mission accomplished.
UPDATE: Koen Kooi noted that "Yocto" is only the umbrella project and what I'm fixing here is actually the "poky" build system that's part of the project, so I edited this post for clarity. Thanks for the hint!
Stefan Seyfried
posted at
Fix openSUSE's grub2 for Virtualization and Servers
After installing current openSUSE Factory in a VM, I found that the old GRUB option was removed from YaST2. I knew this from the mailing list, but now I actually realized that this happened. I still prefer GRUB over GRUB2, because for me it is easier to manage. But being lazy, I just went with the default.
Everything went well, until I added a customized kernel (I had installed the VM to do some kernel experiments after all). The boot menu suddenly was not very useful anymore. After selecting "advanced options", I got the following:
There is no such thing as in old GRUB where "Esc" got you out of gfxboot mode and into text mode. The command keys, like "e" for editing the current selection and "c" for a GRUB2 shell (something even more hellish than the old GRUB shell apparently) work, but you really need to know this, as there is no indication of that.
So I wanted to get rid of the gfxboot stuff. I don't need fancy, I need it usable.
Booted the VM, logged in. "zypper rm grub2-branding-openSUSE" followed by "grub2-mkconfig > /boot/grub2/grub.cfg". Much better:
But still it is in graphics mode, which I do not care about now, but once I have to deploy this stuff on something like an HP server where you can get a text console via SSH, but only if it is in plain VGA mode, I will not be amused. So boot that VM again, and look further. Finally, the solution is in /etc/default/grub: "GRUB_TERMINAL=console". The comment above says just uncommenting the original "gfxterm" setting would be enough, but it is not. After recreating the config file and rebooting, it looks quite useful:
And it is not even missing information, compared to the gfxterm version... no idea why this stuff is default.
Now that "Distribution" string in there looks completetly redundant, so getting rid of that will help, too.
Again, it is in /etc/default/grub, variable GRUB_DISTRIBUTOR. I see that in the grub2 rpm package, there is only "openSUSE" instead of "openSUSE Factory Distribution", so it might be put into the config by the installer or something. I'll change it to just "Factory" (to distinguish between other openSUSE installations). After grub2-mkconfig, it looks almost good:
Now the important information (Kernel version) is completely visible. Much better than the original "bling bling" screen, which had no useful information at all...
Just fixing the Factory string would probably have helped also, but it still would fail the server test, so plain console will stay my favorite for now.
Everything went well, until I added a customized kernel (I had installed the VM to do some kernel experiments after all). The boot menu suddenly was not very useful anymore. After selecting "advanced options", I got the following:
Well, which one of the four is now my hand-built, brand new kernel?
There is no such thing as in old GRUB where "Esc" got you out of gfxboot mode and into text mode. The command keys, like "e" for editing the current selection and "c" for a GRUB2 shell (something even more hellish than the old GRUB shell apparently) work, but you really need to know this, as there is no indication of that.
So I wanted to get rid of the gfxboot stuff. I don't need fancy, I need it usable.
Booted the VM, logged in. "zypper rm grub2-branding-openSUSE" followed by "grub2-mkconfig > /boot/grub2/grub.cfg". Much better:
Now that "Distribution" string in there looks completetly redundant, so getting rid of that will help, too.
Again, it is in /etc/default/grub, variable GRUB_DISTRIBUTOR. I see that in the grub2 rpm package, there is only "openSUSE" instead of "openSUSE Factory Distribution", so it might be put into the config by the installer or something. I'll change it to just "Factory" (to distinguish between other openSUSE installations). After grub2-mkconfig, it looks almost good:
Just fixing the Factory string would probably have helped also, but it still would fail the server test, so plain console will stay my favorite for now.
Jakub Steiner
posted at
Making of GNOME 3.14
The release of GNOME 3.14 is slowly approaching, so I stole some time from actual design work and created this little promo to show what goes into a release that probably isn't immediately obvious (and a large portion of it doesn't even make it in).
I'd like to thank all the usual suspects that make the wheels spinning, Matthias, Benjamin and Allan in particular. The crown goes to Lapo Calamandrei though, because the amount of work he's done on Adwaita this cycle will really benefit us in the next couple of releases. Thanks everyone, 3.14 will be a great release! (I keep saying that every release, but you simply feel it when you're forced to log in to your "old" GNOME session rather than jhbuild.)
Berthold Gunreben
posted at
Multiple Linux Consoles in z/VM
The standard method to access z/VM is using a 3215 terminal with a terminal emulator. With linux, the x3270 package provides a free emulator for these terminals.
One of the features of z/VM is, that you can define several consoles for a guest. This is very helpful if there are problems with a guest that affect the network connectivity. With z/VM you can even define multiple consoles that allow direct logon to the running guest.
By default, only one terminal is defined for z/VM guests. To define three additional 3270 consoles on a guest at the addresses 0020-0022, use the following commands:
cp define graf 20 cp define graf 21 cp define graf 22
These consoles can also be created online from linux, provided that you got sufficient privileges on the guest. To issue cp commands from linux, use the command vmcp instead of cp.
With SLES 12, several additional steps are needed to activate these consoles.
First, the devices must be made available to the system. This a twofold process:
- Remove the devices from the cio ignore list with the command
- Add the devices to /boot/zipl/active_devices.txt to make this change persistent.
# cat /boot/zipl/active_devices.txt ... 0.0.0020-0.0.0022
cio_ignore -r 0.0.0020-0.0.0022
The system automatically detects those devices. The corresponding serial devices are found below /dev/3270/tty[123]. Next, tell systemd to run a getty on these devices:
systemctl enable serial-getty@3270-tty1.service systemctl enable serial-getty@3270-tty2.service systemctl enable serial-getty@3270-tty3.service systemctl start serial-getty@3270-tty1.service systemctl start serial-getty@3270-tty2.service systemctl start serial-getty@3270-tty3.service
To use the new consoles on a machine called LINUX065, direct the 3270 terminal emulator at z/VM. Instead of logging on as regular user, move the cursor to the COMMAND line and enter the following command:
dial linux065
To redisplay the logon prompt, you might want to press enter once.
When trying to logon to this console as root, you will find that it won’t let you. The reason for this is, that root logon is only allowed on previously defined consoles. The configuration file for this is /etc/securetty. Add the following lines to the end of this file:
3270/tty1 3270/tty2 3270/tty3
After this, you can directly logon to the linux guest without the need for z/VM credentials.
If you want to avoid the need to redefine the consoles after a logoff of the guest, add the definition to PROFILE EXEC A of the guest.