Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment: Re: KDBus - another systemd brick on the wall (Score 1) 177

by kthreadd (#49558721) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS
Most users will run the combination of kernel and systemd which their GNU/Linux distribution ships. If your application does not work with that kernel then why don't you run an older distribution until the problem has been fixed? At the least running a newer kernel should be your goto solution before downgrading to an unsupported version.

Comment: Re: systemd sux (Score 1) 398

by kthreadd (#49555485) Attached to: Debian 8 Jessie Released
Nothing wrong with using Fedora in production. It depends on what you want. If you want stable and boring the no, don't use Fedora. But if you want to use the latest technology and is OK with rolling forward every 6-12 months then Fedora is actually a great OS to run in production. There's a reason why "software collections" is a big feature in RHEL, and that is that it's more and more common that you actually need newer versions than what's in your "enterprise" distribution. And if that's the case then using a newer distribution could actually be the right solution. There are of course reasons why you wouldn't use Fedora. If you want a support contract or require certain certifications then use RHEL or something else.

Comment: Re:Debian 8 so far, so good (Score 1) 398

by kthreadd (#49553995) Attached to: Debian 8 Jessie Released

systemd has to be pinned to -1 or your servers will get upgraded to it without any interaction from your part.

Of course it gets installed, it's the default init system in Jessie. Most users would expect to have it installed when upgrading, considering that it's a major new feature in Jessie and meant as a replacement for sysvinit.

Beware also that Apache configurations change.

Apache went from 2.2 to 2.4, which in Apache speak is pretty much a major version change. There were lots of changes in 2.4, especially making the event-based mpm the default. But there's also a lot of other changes so expect that you have to go through and possibly change a lot of configuration. I also have a number of custom Apache modules that had to be partly rewritten. But once that was done things have been running just fine.

Comment: Re:File manager without file, edit, view.. (Score 1) 398

by kthreadd (#49553797) Attached to: Debian 8 Jessie Released
GNOME applications works just fine with other desktop environments and window managers. What used to be the biggest concern, the app menu, is no longer handled by adding a separate menu bar in the window with just for that menu. Instead, most applications show it as a button in the headerbar when not run within GNOME.

+ - GCC 5.1 Released->

Submitted by kthreadd
kthreadd writes: Version 5.1 of GCC, the primary free software compiler for GNU and other operating systems, has been released. Version 5 includes many changes from the 4.x series. Starting with this release the default compiler mode for C is gnu11 instead of the older gnu89. New features include new compiler warnings, support for Cilk Plus. There is a new attribute no_reorder which prevents reordering of selected symbols against other such symbols or inline assembler, enabling link-time optimization of the Linux kernel without having to use -fno-toplevel-reorder. Two new preprocessor directives have also been added, __has_include and __has_include_next, to test the availability of headers. Also, there's a new C++ ABI due to changes to libstdc++. The old ABI is however still supported and can be enabled using a macro. Other changes include full support for C++14. Also the Fortran frontend has received some improvements and users will now be able to have colorized diagnostics, and the Go frontend has been updated to the Go 1.4.2 release.
Link to Original Source

Comment: Re:Poor Design... (Score 1) 73

by kthreadd (#49525791) Attached to: Networking Library Bug Breaks HTTPS In ~1,500 iOS Apps
OS X actually has perfectly fine support for shared libraries. They are supposed to be installed under /Library/Frameworks, and there are some applications that do that. There's no reason why they couldn't do that on iOS as well, just let developers share frameworks on the App Store and build a mechanism into the App Store where an app can require other apps or frameworks.

If it happens once, it's a bug. If it happens twice, it's a feature. If it happens more than twice, it's a design philosophy.

Working...