Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment: Re: systemd sux (Score 1) 362

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) 362

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) 362

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.

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

by kthreadd (#49525691) Attached to: Networking Library Bug Breaks HTTPS In ~1,500 iOS Apps

Non system libraries are statically linked .a files in IOS. Apple insists on this, although I'm not entirely sure why. I guess its to avoid DLL hell.

Managing shared libraries across applications works fine in a GNU distribution where the distribution takes responsibility for all applications. With Apple's approach there's no good way to manage this, different applications might use their own specialized version of the library. At most you might have an opt-in system where developers can register the libraries they are using and the version they require, and have the system download and manage them for them.

Comment: Re:And this is why corporations don't trust the GP (Score 1) 225

by kthreadd (#49424897) Attached to: How Ubiquiti Networks Is Creatively Violating the GPL

If "you" are a one-man shop, that's fine.

If "you" are the legal department for a company with 10,000 developers, the GPL is scary. You can either blanket-ban GPL code, and make your life easy, or create a system for separately evaluating the use of each and every piece of GPL code you allow in, plus some auditing process to catch cheaters (who check in GPL code as their own work, which happens).

Cloud services companies usually go with the latter: because you don't have to share your code if you don't distribute it, the payoff is good to allow use of GPL code, and police the corner cases where you do distribute code. Blanket bans on GPL code are still common at old-school software companies.

Most non-free licenses are quite scary too, but they often get a pass since they are not that open to begin with.

NOWPRINT. NOWPRINT. Clemclone, back to the shadows again. - The Firesign Theater

Working...