Years ago I used a CMS to bring content to a web page. But with evolving CSS, markdown syntax and comfortable git hosting, publication of smaller sites can be handled without a CMS. My home page is translated. Thus I liked to express page translations in a stateless language. The ingredients are simple. My requirements are:

• stateless CSS, no javascript
• integrable with markdown syntax (html tags are ok’ish)
• default language shall remain visible, when no translation was found
• hopefully searchable by robots (Those need to understand CSS.)

CSS:

/* hide translations initially */
.hide {
  display: none
}
/* show a browser detected translation */
:lang(de) { display: block; }
li:lang(de) { display: list-item; }
a:lang(de) { display: inline; }
em:lang(de) { display: inline; }
span:lang(de) { display: inline; }

/* hide default language, if a translation was found */
:lang(de) ~ [lang=en] {
 display: none;
}

The CSS uses the display property of the element, which was returned by the :lang() selector. However the selectors for different display: types are somewhat long. Which is not so short as I liked.

Markdown:

<span lang="de" class="hide"> Hallo _Welt_. </span>
<span lang="en"> Hello _World_. </span>

Even so the plain markdown text looks not as straight forward as before. But it is acceptable IMO.

Hiding the default language uses the sibling elements combinator E ~ F and selects a element containing the lang=”en” attribute. Matching elements are hidden (display: none;). This is here the default language string “Hello _World_.” with the lang=”en” attribute. This approach works fine in FireFox(49), Chrome Browser(54), Konqueror(4.18 khtml&WebKit) and WP8.1 with Internet Explorer. Dillo(3.0.5) does not show the translation, only the english text, which is correct as fallback for a non :lang() supporting engine.

On my search I found approaches for content swapping with CSS: :lang()::before { content: xxx; } . But those where not well accessible. Comments and ideas welcome.

Релиз Fedora 25 запланирован на 15 ноября, а openSUSE 42.2 — на день позже. На самом деле, оба этих дистрибутива я тестирую уже около месяца, установив ещё бета-версии. У меня есть некоторые наблюдения, которыми я хочу поделиться.

Fedora

Это очень достойный и довольно стабильный дистрибутив, который прекрасно подойдёт для домашнего использования, если вы возьмёте не официальную версию, а сборку от проекта Russian Fedora — в ней уже добавлены дополнительные репозитории, кодеки и прочие штуки, которые в обычной Федоре нужно проделывать вручную. Даже если вы не собираетесь использовать Федору как основную систему, её всегда полезно иметь где-нибудь под рукой (в виртуальной машине или на отдельном жёстком диске/разделе), потому что Федора — это всегда самая новая версия рабочего стола Gnome, передовая и самая стабильная работа новой графической системы Wayland, надёжная и стабильная поддержка UEFI и Secureboot в инсталляторе, огромный выбор стороннего ПО через систему Fedora Copr и многое другое.

Вместе с тем, пользоваться Fedora 25 Beta как основной системой затруднительно, потому что многие проекты в Copr пока не делают сборок для версии 25, многие инструменты, вроде Fedy, тоже пока поддерживают только версии Fedora вплоть до 24-й. Короче говоря, надо просто немного подождать.

В середине октября моя Russian Fedora 25 Beta вдруг перестала обновляться и вообще видеть сервера обновлений. Я догадался заглянуть на страницу состояния инфраструктуры Федоры и увидел там много красного цвета. Инфраструктура всего проекта «лежала» примерно 2 часа по вине урагана «Матфей», который вызвал наводнения и обрыв электропередач в местечке Raleigh, где и расположен дата-центр Fedora Project. Казалось бы, Fedora умеет искать местные зеркала своих репозиториев во всех частях мира, однако сам список зеркал всё равно сначала подтягивается из США. Так что при использовании стандартных настроек пакетного менеджера DNF, работоспособность Russian Fedora всё равно критично зависит от американских серверов.

openSUSE

Предыдущий релиз 42.1 мне откровенно не понравился — он был очень «сырым» и стал более-менее хорошим только через пару-тройку месяцев, когда большинство проблем разработчики наконец решили. Я использую openSUSE ещё со времён версии 10.2 и могу сказать, что за прошедшее время было много как хороших, так и неудачных релизов —  в этом смысле проект openSUSE остаётся непредсказуемым. Правы были те пользователи, которые не стали обновляться до Leap 42.1 и остались на отличных версиях 13.1 и 13.2. Но похоже, что грядущий выпуск 42.2 получится исключительно удачным. За месяц активного использования я остался очень доволен качеством и производительностью системы. Пожалуй, стоит перечислить достоинства и некоторые выявленные недостатки в openSUSE 42.2.

Достоинства:

• Традиционно лучший инсталлятор из виденных мною. Логичный, удобный, стабильный — оно и не мудрено, ведь готовили его изначально для платной версии SUSE SLE:
• Приятный в использовании и очень производительный рабочий стол Plasma5;
• Огромный набор дополнительного ПО в системе openSUSE Build Service (OBS). Здесь много энтузиастов из сообщества openSUSE поддерживают свои сборки пакетов, и тут есть практически всё;
• Пакетный менеджер Zypper, который, на мой взгляд, гораздо мощнее любого apt или urpm*. На моей практике мне удавалось легко и изящно откатывать систему к предыдущему состоянию после обновления из «левых» репозиториев, используя Zypper. Сломать пакетную систему в openSUSE практически нереально — даже загубленную систему всегда можно вернуть в строй, вычистив её от ненужных наслоений;
• Интересные возможности бэкапа и версионирования системы благодаря файловой системе Btrfs. В последний раз я тестировал Btrfs ещё с openSUSE 13.1, и тогда меня неприятно удивила низкая производительность этой ФС на десктопе. С тех пор я всегда форматировал корневой раздел для openSUSE в ext4, но недавно я решил поставить 42.2 RC на отдельный жёсткий диск и оставил в инсталляторе настройки по умолчанию — они-то и предлагают всегда Btrfs. В итоге, установленная система показалась мне очень быстрой, и теперь мне больше не хочется менять Btrfs на ext4. Кстати, недавние тесты показывают, что Btrfs не так уж и отстаёт от конкуренток;
• Самый удобный способ установки обновлений, что я когда-либо видел. В системном лотке Plasma5 сидит значок обновлений, который подаёт сигнал о новых версиях пакетов. Достаточно всего двух щелчков мыши — и обновления тут же скачиваются и устанавливаются!

Недостатки:

По мелочи всегда набираются ошибки, которые хоть и не сильно влияют на общее впечатления о системе, но раздражают. Так, при выходе (log out) из Plasma5 эта самая Плазма сначала замирает на пару секунд, потом с ошибкой перезапускается, и лишь после этого сеанс завершается. Есть надежда, что это исправят в ближайших выпусках Plasma 5.8.х, так что нужно просто подождать обновлений. В остальном, некоторые программы всё равно приходится собирать вручную (KEncFS, KNemo), но их немного. Русификация Plasma5 в целом на «четвёрку» — чуть похуже чем в Rosa Fresh, но мелкие огрехи не сильно портят жизнь.

Самое главное — openSUSE 42.2 ещё до своего выхода оказался очень стабильным и пригодным для использования дистрибутивом, который я могу рекомендовать всем, кто интересуется Linux.

This tutorial will show you about how to install VirtualBox on openSUSE Leap or another version and another .rpm distro. Because i’m using openSUSE Leap as my operating system.

VirtualBox is one of powerfull virtualization software. For developer you can use VirtualBox to create or manage your project without disrupt your main device,  those are isolated. I’m using virtualbox for trying an another linux distro without destroy my Laptop.

VirtualBox can be combine with Vagrant. Wait for the next tutorial!

Check this out:

Requirements

1. openSUSE Leap
2. Internet Connection
3. VirtualBox, you can download it here.

Installation

• Install dependencies for VirtualBox, it requires gcc, kernel-devel, dkms and make.

zypper in gcc make kernel-devel dkms

• Download and install public key for signed,

wget -c https://www.virtualbox.org/download/oracle_vbox.asc
rpm --import oracle_vbox.asc

• Navigate to your download folder of VirtualBox, and run this command:

zypper in VirtualBox-xxxx.rpm

• As root, open YaST | go to Security and Users | User and group management. Select your username from the list, then click Edit. Go to the tab named Details, then tick the group vboxusers in order to add your username to that group.

• Okay, VirtualBox is ready to use. If you using KDE you can find in by search or go to Application Menu | System | Oracle VM Virtualbox.

Hope this helpful

The post How To Install VirtualBox Latest Version on openSUSE Leap appeared first on dhenandi.com.

Now, i will show you how i did install VMware Workstation on my openSUSE Leap 42.1.  Maybe this tutorial can be reference by another Linux Distro.

I want to tell you a little about my workplace, my workplace related with this tutorial because i got VMware Workstation License in my workplace haha :-D. My Workplace is a VMware Partner, and they are got a NFS (Not For Sale) License. So i use it.

Okay, Check this out!

Requirement

1. Linux openSUSE Leap 42.1
2. VMware Workstation 12, you can download at here. (with .bundle format)
3. VMware Workstation 12 License

Installation

• Install dependencies for VMware Workstation, VMware Workstation need gcc and kernel-devel

zypper in gcc kernel-devel

• Go to your download folder and give execute permission

chmod +x VMware-Workstation-xxxxxxx.bundle
./VMware-Workstation-xxxxxxx.bundle

• Follow the wizard, and voilaaa. VMware Workstation Ready for use

The post How To Install VMware Workstation 12 on openSUSE Leap 42.1 appeared first on dhenandi.com.

I’ve been keeping an eye on Rust for a while now, so when I read Alberto’s statement of support for more Rust use in GNOME, I couldn’t resist piling on…

From the perspective of someone who’s quite used to C, it does indeed seem to tick all the boxes. High performance, suitability for low-level tasks and C ABI compatibility tend to be sticking points with new languages — and Rust kills it in those departments. Anyone who needs further convincing should read up on Raph Levien’s font renderer. The usual caveat about details vis-a-vis the Devil applies, but the general idea looks exactly right. Rust’s expressiveness and lack of baggage means it could even outperform C for non-trivial code, on top of all the other advantages.

There are risks too, of course. I’d worry about adoption, growth and the availability of bindings/libraries/other features, like a good optional GC for high-level apps (there is at least one in the works, but it doesn’t seem to be quite ready for prime-time yet). Rust is on an upwards trajectory, and there doesn’t seem to be many tasks where it’s eminently unsuitable, so in theory, it could have a wide reach: operating systems, platform libraries, both client- and server-side applications, games and so on. However, it doesn’t appear to be the de facto language in many contexts yet. Consider the statement “If I learn language X, I will then be able to work on Y.” Substitute for X: Java, Javascript, Python, ObjC, C, C++, C# or even Visual Basic — and Y becomes obvious. How does Rust fare?

That is, of course, a very conservative argument, while in my mind the GNOME project represents, for better or worse, and C use notwithstanding, a more radical F/OSS philosophy. Its founding was essentially formulated as a revolt against the Qt license (and a limited choice of programming languages!), it was an early adopter of Git for version control, and it’s a driver for Wayland and Flatpak now. For what it’s worth, speaking as mostly a downstream integrator, I wouldn’t mind it if GNOME embraced its DNA yet again and fully opened the door to Rust.

You may be aware that openSUSE Leap 42.2 is now in the release candidate stage, and there’s a lot of activity aimed at squashing those pesky bugs before they hit the final release. One particular bug proved to be quite tough to fix, and it was only solved thanks to the “heroes” mentioned in the title. This is the history of the bug.

The report

October 6th, 2016 - A bug iss reported against Plasma reporting a hard freeze of Plasma when using the Noveau driver, but not with the closed NVIDIA blob. Although the effect is deleterious to Plasma and not other desktop environments, there is evidence that the issue is in the driver itself, but there’s only partial indications, and no conclusive proof.

The problem is that no one of the current KDE team members has access to a NVIDIA card so it’s hard to determine what is actually going on. After thinking over it for a while, I decided it was time to call in the pros. And in KDE, Martin Graesslin of KWin fame is the best bet when graphics and KWin interactions are involved. He suggested to get a backtrace of the freezes and crashes to ensure what exactly is happening. At the same time, Antonio Larrosa from the KDE team tried to get hold of a test system to investigate the cause.

Antonio eventually managed to reproduce the problem with a specific NVIDIA card and Noveau, and his initial results pointed at issues in interactions between the Noveau driver and KWin itself. Martin, being a nice person, also subscribed to the report, and once the bactraces came in he was able to find a solution to the riddle: when using OpenGL, Mesa waited for a buffer and in turn blocked KWin. The net result was an apparent freeze of the workspace when logging in.

Patches had been proposed to fix the issue, but according to upstream Noveau developers, they just made matters worse (instability).

As an aside, Noveau, despite the heroic efforts from its developers, has still several issues when using apparently “normal” workflows: for example any application using QWebEngine will crash on Noveau because while the driver does work well with multi-threaded rendering, the Blink engine uses different threads even when Qt is using single-threaded rendering.

Once the problem was found, the 5 eurocent question was: what can we do to fix the situation?

The hunt for a solution

One major problem with this issue was that not all NVIDIA cards were affected. Only specific models exhibited the problem, which meant blanket-disabling OpenGL for KWin when using Noveau was too restrictive. But at the same time, the only environment affected was Plasma. The situation was extremely dire for the default desktop in openSUSE.

But two of our today’s heroes did not give up. Martin and Antonio sat around a virtual table and tried to work out a solution. Martin suggested to use the same mechanism that KWin used normally to determine if the use of OpenGL is “unsafe” when starting up, disabling it if any problems arose. It didn’t work in the specific case only because the freeze occurred when rendering started, that is past this checkpoint.

The discussion was fruitful. Across the several hypotheses mentioned, Fabian Vogt, also from the openSUSE KDE team, thought about a “dead man’s switch”: KWin would get killed and restarted if a freeze occurred, but disabling OpenGL after the restart. That was enough for Antonio and Martin to come up with a strategy: checking with a timer if KWin was frozen during rendering. If the timer went off, KWin would get killed and restarted automatically, but disabling OpenGL (more technically, activating the “OpenGL unsafe protection”), and now would be able to continue without freezes. Antonio posted his patch for review and that is where we meet another hero of the day, David “d_ed” Edmundson. During the patch review, he asked Antonio what kind of card exhibited the issue, and promptly acted to get one to run tests himself.

Patches went back and forth for a number of days, scrapping one solution after the other, until Martin was finally able to accept the final revision, which was merged by Antonio in the Plasma/5.8 branch of kwin (meaning, everyone will benefit from it). Fabian then proceeded to submit these patches to openSUSE Leap and to openSUSE Tumbleweed.

As final icing on the cake, Antonio was able to come up with a patch to QWebEngine to disable the GPU if Noveau was detected, preventing crashes at the price of reduced performance (and adding two environment variables to force or disable the behavior, respectively).

The bottom line

What could I say: upstream-downstream collaboration is truly awesome, and even more so when such a difficult bug is tackled and fixed. The way my fellow KDE team members acted is truly commendable, and so the behavior of upstream KDE (despite the false “they don’t listen” mantra) that helped and offered assistance in getting a proper solution out.

So if you ever meet Antonio, David, Fabian, and Martin, please offer them a beverage of their choice. They’re the heroes Free Software deserves.

Bottom note

Other noteworthy people need to be mentioned here due to their involvement:

• Dominique Leuenberger and Ludwig Nussel, namely the Tumbleweed and Leap release managers, for keeping up at their jobs (that is, ensuring that awesome software is released timely and properly);
• The SUSE X11 developers, for their assistance on the Mesa side of things;
• The openSUSE community for bug reporting and testing, or this bug would’ve never been discovered.