Debian 8 "Jessie" released
| From: | Paul Wise <pabs-AT-debian.org> | |
| To: | debian-announce-AT-lists.debian.org | |
| Subject: | Debian 8 "Jessie" released | |
| Date: | Sun, 26 Apr 2015 10:28:05 +0800 | |
| Message-ID: | <20150426022805.GA7860@chianamo> |
------------------------------------------------------------------------ The Debian Project https://www.debian.org/ Debian 8 "Jessie" released press@debian.org April 25th, 2015 https://www.debian.org/News/2015/20150426 ------------------------------------------------------------------------ After almost 24 months of constant development the Debian project is proud to present its new stable version 8 (code name "Jessie"), which will be supported for the next 5 years thanks to the combined work of the Debian Security team [1] and of the Debian Long Term Support [2] team. 1: http://security-team.debian.org/ 2: https://wiki.debian.org/LTS "Jessie" ships with a new default init system, systemd. The systemd suite provides many exciting features such as faster boot times, cgroups for services, and the possibility of isolating part of the services. The sysvinit init system is still available in "Jessie". The UEFI ("Unified Extensible Firmware Interface") support introduced in "Wheezy" has also been greatly improved in Jessie. This includes workarounds for many known firmware bugs, support for UEFI on 32-bit systems, and support for 64-bit kernels with 32-bit UEFI firmware (with the latter being included only on our amd64/i386 "multi-arch" installation media). Since the previous release, members of the Debian project have also made important improvements to our supporting services. One of these is a browsable view of all source code shipped in Debian [3] currently available at sources.debian.net [4]. Of course, with over 20,000 source packages, it can be quite daunting to locate the right file. Therefore, we are also very pleased to present Debian Code Search [5], available at codesearch.debian.net [6]. Both services are complemented by a completely rewritten and more reponsive package tracking system [7]. 3: https://www.debian.org/News/weekly/2013/14/#sources 4: https://sources.debian.net 5: https://www.debian.org/News/weekly/2014/17/#DCS 6: https://codesearch.debian.net/ 7: https://tracker.debian.org/ This release includes numerous updated software packages, such as: * Apache 2.4.10 * Asterisk 11.13.1 * GIMP 2.8.14 * an updated version of the GNOME desktop environment 3.14 * GNU Compiler Collection 4.9.2 * Icedove 31.6.0 (an unbranded version of Mozilla Thunderbird) * Iceweasel 31.6.0esr (an unbranded version of Mozilla Firefox) * KDE Plasma Workspaces and KDE Applications 4.11.13 * LibreOffice 4.3.3 * Linux 3.16.7-ctk9 * MariaDB 10.0.16 and MySQL 5.5.42 * Nagios 3.5.1 * OpenJDK 7u75 * Perl 5.20.2 * PHP 5.6.7 * PostgreSQL 9.4.1 * Python 2.7.9 and 3.4.2 * Samba 4.1.17 * Tomcat 7.0.56 and 8.0.14 * Xen Hypervisor 4.4.1 * the Xfce 4.10 desktop environment * more than 43,000 other ready-to-use software packages, built from nearly 20,100 source packages. With this broad selection of packages and its traditional wide architecture support, Debian once again stays true to its goal of being the universal operating system. It is suitable for many different use cases: from desktop systems to netbooks; from development servers to cluster systems; and for database, web, or storage servers. At the same time, additional quality assurance efforts like automatic installation and upgrade tests for all packages in Debian's archive ensure that "Jessie" fulfills the high expectations that users have of a stable Debian release. A total of ten architectures are supported: 32-bit PC / Intel IA-32 (i386), 64-bit PC / Intel EM64T / x86-64 (amd64), Motorola/IBM PowerPC (powerpc for older hardware and ppc64el for the new 64-bit (little- endian)), MIPS (mips (big-endian) and mipsel (little-endian)), IBM S/390 (64-bit s390x) and for ARM, armel and armhf for old and new 32-bit hardware, plus arm64 for the new 64-bit "AArch64" architecture. Want to give it a try? ---------------------- If you simply want to try Debian 8 "Jessie" without having to install it, you can use a special image, known as a live image, available for CDs, USB sticks, and netboot setups. Initially, these images are provided for the amd64 and i386 architectures only. It is also possible to use these live images to install Debian. More information is available from the Debian Live homepage [8]. 8: http://live.debian.net/ If, instead, you want to install it to your computer's permanent storage, you can choose from a range of installation media, such as Blu- ray Discs, DVDs, CDs, and USB sticks, or from the network. Several desktop environments — GNOME, KDE Plasma Desktop and Applications, Xfce, and LXDE — may be installed through CD images; the desired one may be chosen from the boot menus of the CDs/DVDs. In addition, multi- architecture CDs and DVDs are available which support installation of multiple architectures from a single disc. Or you can always create bootable USB installation media (see the Installation Guide [9] for more details). For cloud users Debian also offers pre-built OpenStack images [10], ready to use. 9: https://www.debian.org/releases/jessie/installmanual 10: http://cdimage.debian.org/cdimage/openstack/current/ The installation images may be downloaded right now via bittorrent [11] (the recommended method), jigdo [12], or HTTP [13]; see Debian on CDs [14] for further information. "Jessie" will soon be available on physical DVD, CD-ROM, and Blu-ray Discs from numerous vendors [15] too. 11: https://www.debian.org/CD/torrent-cd/ 12: https://www.debian.org/CD/jigdo-cd/#which 13: https://www.debian.org/CD/http-ftp/ 14: https://www.debian.org/CD/ 15: https://www.debian.org/CD/vendors Upgrading Debian ---------------- Upgrades to Debian 8 from the previous release, Debian 7 (codenamed "Wheezy"), are automatically handled by the apt-get package management tool for most configurations. As always, Debian systems may be upgraded painlessly, in place, without any forced downtime, but it is strongly recommended to read the release notes [16] as well as the installation guide [17] for possible issues, and for detailed instructions on installing and upgrading. The release notes will be further improved and translated to additional languages in the weeks after the release. 16: https://www.debian.org/releases/jessie/releasenotes 17: https://www.debian.org/releases/jessie/installmanual About Debian ------------ Debian is a free operating system, developed by thousands of volunteers from all over the world who collaborate via the Internet. The Debian project's key strengths are its volunteer base, its dedication to the Debian Social Contract and Free Software, and its commitment to provide the best operating system possible. Debian 8 is another important step in that direction. Contact Information ------------------- For further information, please visit the Debian web pages at https://www.debian.org/ or send mail to <press@debian.org>. -- To UNSUBSCRIBE, email to debian-announce-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: https://lists.debian.org/20150426022805.GA7860@chianamo
Posted Apr 26, 2015 4:44 UTC (Sun)
by donbarry (guest, #10485)
[Link]
Posted Apr 26, 2015 16:23 UTC (Sun)
by torquay (guest, #92428)
[Link] (144 responses)
I don't quite agree that "universal operating system" is the right moniker here. Disregarding the hubris of "universal", an operating system is meant to provide stable functionality and services which are then employed by user-facing applications. Can I run apps written for Debian 5 (or 6, 7, or whatever) without recompiling on Debian 8? How about even with recompiling? In both cases it's very iffy and a hit-n-miss affair. This is why there is a broad selection of packages -- to mask the underlying breaks in APIs and ABIs.
Such an approach is not really an operating system, but a mud ball. Debian is of course not alone in this -- every Linux "distribution" has this problem (eg. RHEL). I do understand the huge amout of effort in making this mud ball coherent, and many kudos to all the volunteers for their work. At the same time, wouldn't such effort be better spent in working towards a framework where we don't need to mask the constant API and ABI breaks?
Posted Apr 26, 2015 17:01 UTC (Sun)
by dskoll (subscriber, #1630)
[Link] (4 responses)
Can I run apps written for Debian 5 (or 6, 7, or whatever) without recompiling on Debian 8?
Well obviously, this depends extensively on the apps. I maintain a bunch of apps, both open-source and commercial, and all of them have ported seemlessly to all versions of Debian starting from Sarge (3.1). I did recompile them, but I bet quite a few would have worked even with recompilation. In no cases did I need to modify the sources.
Clearly, if your apps rely on fast-changing toolkits like Gtk or Qt or on new kernel or C library facilities, then you have much more work ahead... but this (as you point out) is not Debian's fault.
Posted Apr 30, 2015 18:04 UTC (Thu)
by mstone_ (subscriber, #66309)
[Link] (3 responses)
Posted May 1, 2015 16:11 UTC (Fri)
by raven667 (subscriber, #5198)
[Link] (2 responses)
Continue to package every different ABI with a unique soname pretty much forever? By avoiding that problem by doing mass recompiles they have papered over the compatibility issues and have hidden the real underlying costs of software maintenance on Linux so there is no pressure to fix it and app developers end up running into these issues head-on.
Posted May 1, 2015 16:21 UTC (Fri)
by mstone_ (subscriber, #66309)
[Link] (1 responses)
There are two big cases where this doesn't work. The first is when the libraries link against things which themselves change their ABI. g++ is notorious for that. There isn't a good solution other than not using g++ or changing the way libg++ is managed. (I think they've tried to improve, but it'll be another 10 years until we see whether they've succeeded.) The other is when upstream breaks the ABI without changing the soname. Then the distributor needs to make a call on whether to do the right thing or keep compatibility with other distros that followed upstream's mistake.
Nothing's been "papered over" doing mass recompiles, it's the only way to take advantage of new functionality. In general, people want different things now than they did in the late 90s, and you can't get those things if you use the same ABIs you used in the late 90s.
Posted May 2, 2015 12:35 UTC (Sat)
by ms_43 (subscriber, #99293)
[Link]
G++ takes C++ standard conformance seriously, and when the latest version of the standard mandates something in conflict with the current ABI, g++ will define a new ABI.
In the most recent case, C++11 std::string in libstdc++ 5.1, it was fortunately possible to provide both the old and the new ABI with the same library, and in such a way that a mis-use (inconsistent _GLIBCXX_USE_CXX11_ABI in compilation units) will cause a link failure.
By way of contrast the SunStudio C++ compiler is (or at least, was a couple years ago) ABI compatible with the version that shipped in the late 90s, but that is achieved by serious gaps in C++98 standard conformance, such as the wrong name mangling of functions with const/volatile qualified parameters.
Posted Apr 26, 2015 18:02 UTC (Sun)
by scientes (guest, #83068)
[Link]
Posted Apr 26, 2015 18:19 UTC (Sun)
by tialaramex (subscriber, #21167)
[Link] (4 responses)
At every moment on the one hand you still want to run programs written last week, when Extreme Zorbian Snorflex was the most exciting new thing ever and Flabouge didn't exist yet, and yet you also want to be ready to run programs written this week, which obviously require Fully Trenoxic Flabouge and couldn't care less about any sort of Snorflex because they're not for your grandparents to run on an abacus.
There isn't actually that much in common between the "text rendering API" that was suitable for writing my name on the TV using a ZX81 and the one used to render 习近平 (the current Leader of China) on a 3cm colour LED touchscreen strapped to someone's wrist. Things changed. A lot of things.
Obviously we could strive to do _better_ but I want to be clear that it's unrealistic to pretend that this just shouldn't happen at all or that NOW we know what the APIs will need to look like for the rest of time and no further breaks are necessary or to be expected.
Posted Apr 27, 2015 13:10 UTC (Mon)
by NAR (subscriber, #1313)
[Link] (3 responses)
By the way, the actual workflow was that a legacy code build used imake, worked on the former computer, didn't work on the later. I checked which package contains imake, found that xorg-x11-util-devel, checked the other computer and found that there's no package with name like that. A package with similar name didn't contain imake. Then off to the internet to find out which package might contain imake. An no, yum and stuff like that doesn't help due to excessive amount of NAT and firewalls between the second computer and the public internet.
Posted Apr 28, 2015 19:46 UTC (Tue)
by zuki (subscriber, #41808)
[Link] (2 responses)
Transaction Summary
Total download size: 263 k
Posted Apr 29, 2015 10:00 UTC (Wed)
by NAR (subscriber, #1313)
[Link] (1 responses)
Posted Apr 29, 2015 14:52 UTC (Wed)
by zuki (subscriber, #41808)
[Link]
My main point was that you shouldn't rely on a specific package name — which is subject to change. You can use dependencies on specific filenames. You can also use dependencies on various virtual provides. For things like java, Requires:mvn(com.carrotsearch:hppc) is much better than Requires:hppc. RPM will automatically generate dependencies on .so files: Requires:libseccomp.so.2()(64bit) is much better than Requires:libseccomp. Similar support exists for pkg-config, PERL, and bunch of other things. This gives package managers freedom to rename/split/combine packages without breaking dependencies.
Posted Apr 26, 2015 20:04 UTC (Sun)
by epa (subscriber, #39769)
[Link] (4 responses)
Posted Apr 28, 2015 0:41 UTC (Tue)
by xxiao (guest, #9631)
[Link] (3 responses)
Posted Apr 28, 2015 9:49 UTC (Tue)
by epa (subscriber, #39769)
[Link] (2 responses)
Posted Apr 28, 2015 17:28 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
no, stable releases are supported until 1 year after the next stable release.
Now, in practice this all too frequently means 5 years or more of support, but Debian has made noises about trying to do a new stable release every 2 years, which would limit support to 3 years.
Posted Apr 28, 2015 18:29 UTC (Tue)
by Jonno (subscriber, #49613)
[Link]
> no, stable releases are supported until 1 year after the next stable release.
At which point it becomes an lts release and is supported as such until 5 years after initial release.
In Debian "lts" isn't a particular release, it is a release _stage_ all releases (starting with Debian 6, aka squeeze) goes through.
Posted Apr 26, 2015 20:19 UTC (Sun)
by storner (subscriber, #119)
[Link] (1 responses)
It still runs on Debian 8 today. Don't use it much, but I have some files lying around that it will happily open up.
Posted Apr 27, 2015 2:47 UTC (Mon)
by rsidd (subscriber, #2582)
[Link]
Depends how late in the 1990s. StarOffice supported Linux since version 3.1 in 1996, and "Caldera Internet Office Suite" (mainly the WordPerfect word processor and NexS spreadsheet, plus an email program) shipped in 1996 too.
Posted Apr 27, 2015 2:16 UTC (Mon)
by alfille (subscriber, #1631)
[Link] (123 responses)
Posted Apr 27, 2015 3:12 UTC (Mon)
by torquay (guest, #92428)
[Link] (122 responses)
I think the first step would be to acknowledge that insisting on non-bundled libraries creates too much work (witness the recent Chromium and QtWebKit sagas). Bundled libraries et al are part of the solution, as long as people insist on breaking APIs and ABIs willy nilly.
Secondly, the current package management (rpm, deb, whatever) is too fine grained. Something along the lines of docker containers and/or Ubuntu's effort with the Snappy approach are steps in the right direction. Entire frameworks should be installed in one hit, instead of single components that have 50 bazillion dependencies on other single components.
Posted Apr 27, 2015 3:35 UTC (Mon)
by Sesse (subscriber, #53779)
[Link] (113 responses)
Posted Apr 27, 2015 4:57 UTC (Mon)
by torquay (guest, #92428)
[Link] (112 responses)
It doesn't have to be "either/or" situation. Apps that want to do dynamic linking with "OS provided" libraries can continue doing so. The point is to allow apps to optionally have bundled libraries, for whatever reason the app authors decided. The reasons can include using modified forms of the libraries, or to simply ensure API and ABI stability. I trust the developers of Chromium and QtWebKit to patch security issues.
Furthermore, the default runtime environment should be be modified so that security breaks in one application do not automatically lead to the compromise of all of the user's data (and/or all data on the system). In other words, every app should run in its own sandbox, and access to data/webcam/capabilities/etc should be done via an explicit permission model (akin to Android).
Posted Apr 27, 2015 5:14 UTC (Mon)
by cas (guest, #52554)
[Link] (109 responses)
more reasonable, less self-centred people understand that a given system is probably going to run dozens of daemons and applications and not one of them is a special snowflake that deserves to ride roughshod over everything else in the system.
good programmers learn to take advantage of the features and benefits of the entire operating system. lazy ones complain and whine and insist that they need to bundle the libraries with their app because it's too much like hard work to make use of the system libs.
Posted Apr 27, 2015 5:49 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (64 responses)
Posted Apr 27, 2015 5:57 UTC (Mon)
by cas (guest, #52554)
[Link] (63 responses)
except for the handful that don't - they're usually by developers who insist that their application is special...so special that it must ignore the system(s) it is running on, do things its own special way, and have its own special bundled versions of common libraries.
because working WITH the operating system or WITH the developers of the libs is too much work. it's far easier to just ignore them both and use either specific (typically either ancient or pre-release bleeding edge) versions of libraries or hacked up versions of them (without bothering to submit patches upstream).
because, don't ever forget, their app is super-special and deserves special treatment.
IMO that really is super special. as in "special needs".
Posted Apr 27, 2015 7:57 UTC (Mon)
by dgm (subscriber, #49227)
[Link] (61 responses)
From the (third-party) developer's perspective, it certainly doesn't look like a "solid base" to run on. It looks a lot more like a mumbo-jumbo without much coherency. And the reason is that Debian (and all the rest of the distros) are not just OSes. They have eaten all the applications, and in the process, they have become the whole System. They live in complete binary isolation, only communicating with the exterior via source code.
This state of affairs, where the *only* reasonable way to run on an OS is to be part of it, is certainly sorry (for third party developers, that is).
But the problem may be that Linux (the Kernel) does a so much better job at this. All the distros carry it, and we know that it can run the same binaries, no matter what distro we chose. So, reasonable people *expect* that those binaries would run. But the distros drop the ball here.
It's not rare the case where a newer version of the distro cannot run an application built for an older one because some library is no longer supported. Unless the application bundles all the required libraries, that is.
So, for me, it's the distros that are at fault. They do a *super* *awesome* work at building a whole system that is inclusive and stable. But they stink at running third party applications. And it's by design. That's the unmitigated truth.
May being aware of the problems take us a little closer to a proper solution.
Posted Apr 27, 2015 18:16 UTC (Mon)
by lsl (subscriber, #86508)
[Link] (59 responses)
Well, how else could they fulfill their purpose? Only with source code they're able to provide a system that works similar over a range of different computer architectures and, in the case of Debian, even OS kernels. The work that distros are doing in this area is very important: we really need a common corpus of software that you can run almost everywhere.
> This state of affairs, where the *only* reasonable way to run on an OS is to be part of it, is certainly sorry (for third party developers, that is).
So why settle for being a "third party"? You can be first-class today. All it takes is one enthusiastic user of your program to maintain it in her favourite distro. Preferably in a way that ensures a good cooperation with the upstream maintainers.
> But the problem may be that Linux (the Kernel) does a so much better job at this. All the distros carry it, and we know that it can run the same binaries, no matter what distro we chose. So, reasonable people *expect* that those binaries would run. But the distros drop the ball here.
Pick your dependencies wisely? There are libraries that go to great lengths to provide a stable interface to applications, just like the kernel does. They might not be able to move as fast as the shiny fancy ones that don't care about those things, but they exist. Deciding to use the flaky stuff and then pointing at the distros is just not fair. They're not able to do much about it except for maintaining their own forks, which just isn't very realistic in terms of available resources.
As an example: Tcl and Perl(*) maintainers generally try hard to keep your programs working. Yet, lots of people decide for Ruby or Node.js which don't care at all about providing a reasonable level of compatibility. Things break, people complain. To distros. Doesn't make much sense to me.
(*): well, Perl fucked up recently, but in general they do ok.
Posted Apr 27, 2015 19:18 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (20 responses)
Oh, and going open source is usually not an option.
> Pick your dependencies wisely? There are libraries that go to great lengths to provide a stable interface to applications, just like the kernel does. They might not be able to move as fast as the shiny fancy ones that don't care about those things, but they exist.
Posted Apr 27, 2015 21:01 UTC (Mon)
by lsl (subscriber, #86508)
[Link] (10 responses)
True. That's why clueful companies try to ensure that the open source packages on whose quality and availability their business depends on are well-maintained.
For custom support you probably don't want to go through the distro, but that's an orthogonal problem anyway.
> Oh, and going open source is usually not an option.
Well, then being a first-class component in most Linux distributions is not going to be an option, either. If your users put up with it, fine.
Posted Apr 27, 2015 21:32 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
And companies that do bother often simply use LTS versions of Ubuntu and RedHat/CentOS.
> Well, then being a first-class component in most Linux distributions is not going to be an option, either. If your users put up with it, fine.
Me neither.
Guess why? Because of attitude like yours. There are simply no compelling reasons for the actual real-life users to actually install a Linux desktop.
Posted Apr 27, 2015 22:06 UTC (Mon)
by ewan (guest, #5533)
[Link] (8 responses)
There's no need to make the Linux desktop a first class friendly environment for proprietary software, that need is already well served. It's a different system for a different niche, and for the equally real if not equally numerous users that it suits, it's working pretty well.
Posted Apr 28, 2015 1:44 UTC (Tue)
by torquay (guest, #92428)
[Link] (2 responses)
That's a vacuous argument. Open-source user facing apps are certainly affected by the hostile environment that is in effect created by all distributions: differing library versions, differing frameworks, random API/ABI breaks from one release to another, etc.
From first hand experience it's a huge amount of frustrating work to ensure that package X works on Fedora, Debian, Ubuntu, Arch, OpenSuse, RHEL, etc. On top of that you need to keep up with all the churn whenever a distro gets updated. It's like stapling jelly to a tree.
Basically there's no such thing as "the" Linux OS. Instead, it's a fragmented mess. Package maintainers do help somewhat, but in my experience they often get things wrong (misconfigurations, etc), and/or are tardy in their response. The variable quality of packaging and packagers is not going to change: it's all volunteer driven, where people are not compelled to get the job done properly in a timely manner.
Posted May 5, 2015 7:05 UTC (Tue)
by jospoortvliet (guest, #33164)
[Link] (1 responses)
And in case parent commenter wonders - this is as much an issue for open as it is for closed due to the massive amount of waste and duplicate work between distros. If your software is even remotely obscure, it won't be well supported and broken and outdated on half the distros it ships on. If you build a fast evolving and improving platform, distro can't even begin to do a half decent job of being a 'solid' base to build on. Check up on the issues we had with the ownCloud client. Yes it is open source and yes, volunteers want to help. No, that doesn't actually help unless we are talking rolling release: these distros invariably fail to keep up and make their users settle on horribly insecure and unstable software. Yes, using an ownCloud client older than a year is a bad idea and that goes for much software-making the promise of LTS that Debian (and others) make is nothing more than a big, fat lie. Yeah, that is what I said. they should get over it and start offering a small and stable base to build on, where software can be provided by those who make it - wiyh easy ways to keep it updated. OBS is a great tech for this, even when it does not solve all problems.
Posted May 5, 2015 8:07 UTC (Tue)
by dgm (subscriber, #49227)
[Link]
You nailed it. Software in frantic evolution should only be released following a rolling model, completely separated from the rest of the system.
On the other hand, software that is mature enough (say LibreOffice) should be released often, but maybe not that often. Or maybe distributions could offer two channels: use the latest and greatest or sleep easy at night and be sure an update would not break your presentation tomorrow.
Finally, the base OS should be released much less often. Maybe every 3 or 4 years, maybe more.
I would love to see Debian attempting this for Stretch (it certainly would fit the name)
Posted Apr 28, 2015 2:10 UTC (Tue)
by dashesy (guest, #74652)
[Link]
Posted Apr 28, 2015 6:12 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Classic Linux desktop's marketshare is shrinking. Pretty soon it's going to be limited to several small niches and then it'll just die off naturally.
Or perhaps it will be sidelined into irrelevance with only a small group of circle-jerking^W^W^W enthusiasts caring about it.
Meanwhile, actually sane implementations of Linux desktop are thriving: ChromeOS, Android and now Valve's SteamOS.
Posted Apr 28, 2015 12:34 UTC (Tue)
by Zack (guest, #37335)
[Link] (2 responses)
Good for them. What's keeping you?
>Classic Linux desktop's marketshare is shrinking.
[citation needed]
>Pretty soon it's going to be limited to several small niches and then it'll just die off naturally. Or perhaps it will be sidelined into irrelevance with only a small group of circle-jerking^W^W^W enthusiasts caring about it.
Whatever you say, magic eight ball.
>Meanwhile, actually sane implementations of Linux desktop are thriving: ChromeOS, Android and now Valve's SteamOS.
Where "sane" means bundling libraries and generally bending backwards to accommodate proprietary software? I'm sorry you don't get to play your favourite games or volunteers are not specifically catering to your petulant needs, but try growing up a little first before trying to make an argument.
> There are simply no compelling reasons for the actual real-life users to actually install a Linux desktop.
Except for when they do, but then they still don't exist, since they're not real Scotsmen. Maybe it's time for you to join these "actual real-life users" and simply start using the hand holding alternatives you yourself have mentioned instead of continuously bitching online about how stupid every single free OS packager and maintainer is because they fail to see your one glorious vision of the perfect Linux system.
Posted Apr 28, 2015 13:10 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Linux Desktop has fallen from 1.53% to 1.16% for Wikimedia services since 2011.
> Where "sane" means bundling libraries and generally bending backwards to accommodate proprietary software?
> I'm sorry you don't get to play your favourite games or volunteers are not specifically catering to your petulant needs, but try growing up a little first before trying to make an argument.
> Except for when they do, but then they still don't exist, since they're not real Scotsmen. Maybe it's time for you to join these "actual real-life users" and simply start using the hand holding alternatives you yourself have mentioned instead of continuously bitching online about how stupid every single free OS packager and maintainer is because they fail to see your one glorious vision of the perfect Linux system.
Me? My company and me personally are supporting projects that are interesting to us. By direct monetary donations (see this star thingie, for example?) or by contributing code to them.
Posted Apr 28, 2015 14:28 UTC (Tue)
by niner (subscriber, #26151)
[Link]
So desktop Linux was actually the desktop system that lost the least (only about a quarter). And you really want us to emulate the losers?
In all other rows of that statistics table non-Android Linux actually increased its market share (one stayed the same). I wonder, why you picked the only one row where the number went down?
Posted Apr 27, 2015 22:50 UTC (Mon)
by cesarb (subscriber, #6266)
[Link]
This is the first time I've heard of that.
As far as I know, Python's interface is a pure C API/ABI, both for embedding Python and for writing Python modules (the documentation for the latest version is at https://docs.python.org/3/extending/index.html and https://docs.python.org/3/c-api/index.html). It doesn't use libffi at all.
It's a long time since I last used Lua, but I embedded it back then, and it was also a pure C API; there was no libffi at all. The same applies to calling from Lua to external code (which I also did).
Just for fun, I checked with "rpm -q --whatrequires" what uses libffi on this computer. The only thing which uses it here seems to be the Arduino IDE.
Posted Apr 28, 2015 7:46 UTC (Tue)
by niner (subscriber, #26151)
[Link] (2 responses)
I actually maintain Python bindings for two different other languages and neither implementation uses libffi. If the rest of your postings (like the one claiming shrinking market share for Linux on desktops) is as informed as this one, we can safely ignore them.
Posted Apr 28, 2015 12:47 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
And yes, it's problematic.
Posted Apr 28, 2015 14:39 UTC (Tue)
by niner (subscriber, #26151)
[Link]
use 5.10.0;
__END__
Posted Apr 30, 2015 7:15 UTC (Thu)
by Vapula (guest, #102287)
[Link] (4 responses)
and many other high profile companies are able to support Linux (some don't even support Mac OS/X, like Altera), I think that it clearly proves that it's not so impossible than you seem to imply. Most of these don't even provide multiple downloads oriented to specific distributions.
Posted Apr 30, 2015 19:48 UTC (Thu)
by HelloWorld (guest, #56129)
[Link] (3 responses)
Posted Apr 30, 2015 19:52 UTC (Thu)
by dlang (guest, #313)
[Link] (2 responses)
or in this case, those insisting that something is incredibly hard to do should not argue with the people doing it and saying that it's easier to support linux than windows
Posted Apr 30, 2015 19:55 UTC (Thu)
by HelloWorld (guest, #56129)
[Link]
Posted Apr 30, 2015 20:36 UTC (Thu)
by bronson (subscriber, #4806)
[Link]
Posted Apr 28, 2015 7:32 UTC (Tue)
by dgm (subscriber, #49227)
[Link] (33 responses)
A few ideas off the top of may head:
* Stablish a trusted person (or stable committee) that marks direction and policy, with ultimate decision power.
With this you get a coherent distro, but it's not enough. To really gain interoperability you need to do it all *with* the rest of the _people_ in other distros (those interested, at least).
* All the people working on a distro should be talking regularly with their homologues in other distros. Standards for interoperability should be promoted, based on mutual agreement. When possible, work should be shared.
There are a million more things one should do. Some of those are being done already, but inconsistently. And often stuff is hidden in private mail exchanges and IRC logs.
Posted Apr 28, 2015 17:26 UTC (Tue)
by dlang (guest, #313)
[Link] (32 responses)
>* Pick libraries and daemons wisely, avoid duplication of function. Ensure that binary compatibility is maintained by working closely with library developers. Never, ever, break Application Space. If some library provider gets too adventurous, fork.
So if distro A picks library A for a function and distro B picks library B for a function you would be happy to have to support using both libraries in your code?
Or are you saying that you would rather your application doesn't run on distro B because they picked a different library for that function than you did?
The reason distros support so many different ways of doing the same thing is that they are supporting the applications that people actually write and support.
Posted Apr 29, 2015 9:39 UTC (Wed)
by dgm (subscriber, #49227)
[Link] (4 responses)
If they offer the same interface, certainly. It would be quite an improvement.
> Or are you saying that you would rather your application doesn't run on distro B because they picked a different library for that function than you did?
Given an agreed upon common interface, if distro B wants to break compatibility (and applications) then it's their prerogative. Users will move on.
> The reason distros support so many different ways of doing the same thing is that they are supporting the applications that people actually write and support.
But the problem is that they effectively do not. Binary applications do not work across distributions, or different versions of the same distribution, so supporting all those libraries is not helping certainly.
Anyway, what I am advocating is not removing libraries. Rather, it's choosing one, and adopt it as *the* library, whose interface is going to (somehow) be supported forever, so that programs written today will continue to work in 10 years, unmodified. This, obviously, cannot be done in isolation. All the major distros have to work together. And also the library creators and maintainers. There has to be a compromise of keeping interfaces stable and making backwards compatibility a sine-qua-non feature.
Posted Apr 29, 2015 18:21 UTC (Wed)
by dlang (guest, #313)
[Link] (3 responses)
> If they offer the same interface, certainly. It would be quite an improvement.
why would the two libraries offer the same interface?
It's not like there is only one way to do things, or even an objective way to evaluate if one interface is better than another for any two interface (although there are problems that you can point out in some interfaces that indicate that they have problems)
Even different ways of thinking about the same problem can result in different interfaces, and which interface is 'best' is going to vary depending on how you think about it.
Wishing for the 'one true interface' that all library authors and developers would use is no more useful that wishing for the 'one true language' that everyone would use.
Posted Apr 30, 2015 15:13 UTC (Thu)
by dgm (subscriber, #49227)
[Link] (2 responses)
Posted Apr 30, 2015 18:16 UTC (Thu)
by dlang (guest, #313)
[Link] (1 responses)
Posted May 4, 2015 8:22 UTC (Mon)
by dgm (subscriber, #49227)
[Link]
Posted Apr 30, 2015 4:49 UTC (Thu)
by tcrever (guest, #69157)
[Link] (26 responses)
If we follow this idea maybe we don't need an entire new distribution as we usually understands it but just the library download mechanism. Maybe we can try to see it as a "Library Distribution" that could be installed on top of debian/redhat distributions, just to provide the linked libraries with the stable ABI.
The key problem I see is how to make developers use this mechanism. It needs to include a bootstraper to check the dependencies. Probably creating a tool for packaging and generating the deb/rpm. It would be an installer tool because it is a concept developers are familiar with and installation is a good moment for downloading the app dependencies.
Posted Apr 30, 2015 5:41 UTC (Thu)
by cas (guest, #52554)
[Link] (25 responses)
actually, it's a completely unreasonable way to solve the problem. what you will finish with is a complete and utter mess, with no way to even tell what libs are installed on the system, or where, let alone uninstall or upgrade them in any clean manner.
installing and managing software is a complicated task that has required years of development effort in the tools and especially in the packaging policies and standards - this is not something that can simply be replicated with wget and sudo. unfortunately, lazy programmers think that it is because it's a quick hack to get an unpleasant and boring task done without having to think too hard about it.
quick and dirty hacks like you propose are not scalable. it may seem "mostly harmless" if it's only one or two apps that do it but if every app did it and/or it was the recommended procedure for getting libs or other deps installed it would quickly become a nightmare mess: unmanagable, unmaintainable, and un-upgradable.
this problem is already solved and has been for years with:
1. versioned libraries - it's trivial to have multiple versions of shared libraries installed on a system.
this, to answer another question on this thread is why shared lib packages are separate from -devel packages - you can have multiple shared libs easily but it's a major PITA to have multiple versioned header files for libraries.
2. packaging systems like deb and rpm with dependencies. with the sole exception of installer packages for non-free software (e.g. the flash and chrome installer packages in debian) apps should never download and install binaries themselves. their packages should declare dependancies on library packages or whatever other packages they need AND LEAVE IT UP TO THE PACKAGING SYSTEM TO RESOLVE DEPENDENCIES, DOWNLOAD AND INSTALL THEM.
the correct solution for devs who need a library in a distro is to either package it themselves (i.e. as a separate package, not just bundled with their app) or get one of the distro's devs to package it. this is not a difficult thing to do in either debian or fedora, and once it's in one of them the package will end up in all their derivative distros.
if it's packaged properly, it's available to all users/devs on that distro, not just themselves...and, from the lazy devs POV, it's no longer their problem.
yes, this requires some discipline and some big-picture systems thinking on the part of devs. if that's beyond them then they should fuck off and do something more in line with their talents...i suggest learning how to say "would you like fries with that?" with some sincerity in their voice.
> The key problem I see is how to make developers use this mechanism.
the key problem is to stop developers from doing stupid shit like this.
their software should be developed with the system(s) (i.e. RH or debian or whatever) it is going to run on in mind, not completely ignored at best or treated as a problem to work around at worst.
Posted Apr 30, 2015 11:12 UTC (Thu)
by HelloWorld (guest, #56129)
[Link] (16 responses)
> the correct solution for devs who need a library in a distro is to either package it themselves (i.e. as a separate package, not just bundled with their app) or get one of the distro's devs to package it. this is not a difficult thing to do in either debian or fedora, and once it's in one of them the package will end up in all their derivative distros.
Basically you're proposing to stick with the traditional distro model and deny the very real problems with it. Here are some quotes for you:
Posted Apr 30, 2015 20:31 UTC (Thu)
by cas (guest, #52554)
[Link] (15 responses)
actually, it does. if they're that fucking incompetent then stop using their software. use something else - anything else - instead.
like i said, it takes discipline - including the discipline to stop using crap software.
> Application developers want users to be able to run their software
in other words, "waah! waahh! what app developers want is so important that everything else must be dropped to satisfy their every desire."
in real life, devs who think like that should grow up or fuck off.
> Basically you're proposing to stick with the traditional distro model
the few problems with it are trivial and minor compared to the enormous fucking mess of letting devs do whatever the fuck they want without any discipline. that way lies madness, and it's what we used to have before systems admins started making distros like debian.
the recent fad of devops (which can be a good thing when it means sysadmins working closely with devs to get shit done but more commonly is a terrible thing because it means a bunch of devs going "woohoo! we can do whatever we want without a fascist sysadmin telling us to do it properly") is sending us back to that messy past.
Posted Apr 30, 2015 21:58 UTC (Thu)
by HelloWorld (guest, #56129)
[Link] (14 responses)
TL;DR: you're out of touch with reality and don't know what the fuck you're talking about. EOD.
Posted Apr 30, 2015 22:25 UTC (Thu)
by gdt (subscriber, #6284)
[Link] (5 responses)
not being able to ship a critical library update means my company gets sued for damages With respect, I can't recall such a case. Software licenses do seem very firm on the point of liability and the lack of relief available to licensees for damages. But of course someone could sue anyway. An example rather than an assertion would be very illuminating. As a heavy user of Linux I do see many Java "enterprise" applications shipping with libraries with known security holes. So what motivates you doesn't apply to a great many companies shipping software for Linux.
Posted May 1, 2015 2:01 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Posted May 1, 2015 9:16 UTC (Fri)
by HelloWorld (guest, #56129)
[Link] (3 responses)
Posted May 1, 2015 18:47 UTC (Fri)
by dlang (guest, #313)
[Link] (2 responses)
But if you do want to depend on such new releases, the way to do this isn't to ship an entire OS (i.e. container), it's to create your own repository (ubuntu PPA or similar) and populate it with the libraries that you need. If you put the libraries in the repo using the same naming scheme and similar versions to what the distro does, you can make it so that if the user has an old version of the library, your version will replace it. But when the distro updates the library themselves, it will replace the version that you provide.
This doesn't require a different version of the repo for every release you support, but it does require doing testing against each version (but you have that mostly automated, right?)
For example, rsyslog offers ubuntu packages for a half dozen or so releases, but it's not a half dozen different binaries, each compiled against the latest and greatest version of the libraries available, there are only a couple different versions (due to gnutls messing up it's backwards compatibility)
There are several other programs I use that I don't use the distro provided versions, and instead pull from their repo to my internal repos and deploy from there.
Posted May 1, 2015 19:55 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
We tried first doing multiple overlay repositories. But then we had to support about 10 different repositories for different OS versions. So in the end we decided to simply fucking bundle the world.
Posted May 3, 2015 12:55 UTC (Sun)
by foom (subscriber, #14868)
[Link]
+1. Did the same for a similarish situation, and would do again in a heartbeat.
Posted Apr 30, 2015 22:28 UTC (Thu)
by Zack (guest, #37335)
[Link] (3 responses)
Maybe if some of the company's resources would be diverted to a little quality assurance it wouldn't need to fear being sued by customers so much.
In short: your company sucks at releasing software. Stop blaming distributions for not accommodating your bad practices. That's "reality" for you right there.
Posted May 1, 2015 0:39 UTC (Fri)
by HelloWorld (guest, #56129)
[Link] (2 responses)
> it wouldn't need to fear being sued by customers so much.
> In short: your company sucks at releasing software.
> Stop blaming distributions for not accommodating your bad practices.
Posted May 1, 2015 13:07 UTC (Fri)
by corbet (editor, #1)
[Link]
Yes, you are not the only offender in this particular thread. But why is it always you who pops up in these unpleasant discussions?
Could everybody please calm down a bit and cool it with the playground name-calling?
Posted May 1, 2015 14:26 UTC (Fri)
by HelloWorld (guest, #56129)
[Link]
Posted May 1, 2015 0:31 UTC (Fri)
by flussence (guest, #85566)
[Link] (3 responses)
One could be forgiven for getting such an impression after reading a random selection of your posts here.
Posted May 1, 2015 0:48 UTC (Fri)
by HelloWorld (guest, #56129)
[Link] (2 responses)
Posted May 1, 2015 2:47 UTC (Fri)
by flussence (guest, #85566)
[Link] (1 responses)
I'm sorry that you're offended by someone peeing on your flames.
Feel free to not respond, in fact it'd be much more pleasant for everyone if you didn't.
Posted May 1, 2015 3:15 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Posted Apr 30, 2015 14:45 UTC (Thu)
by cortana (subscriber, #24596)
[Link] (7 responses)
So how do I install libgnutls26 version 2.12.23-18 and 2.12.22-1 at the same time?
Posted Apr 30, 2015 20:23 UTC (Thu)
by cas (guest, #52554)
[Link] (5 responses)
> So how do I install libgnutls26 version 2.12.23-18 and 2.12.22-1
you don't(*). but if the authors of libgnutls26 are in any way competent, you won't need to because the API will not have changed between 2.12.23-18 and 2.12.22-1 - all that should have changed is bug-fixes and improvements.
the API should not change until at least version 3.x
if the API has changed then that is the fault of the library devs, not the distro - and there's nothing that the distro can do it about it so there's no point blaming distros. as i said, it takes discipline on the part of developers - that means lib devs as well as app devs.
this is not difficult to understand. anyone who's in a position to complain about it should be able to understand it easily. if you don't understand it, then that's a problem you need to solve. if you're pretending to not understand it then FOAD - i have no interest in wasting time on arseholes.
(*) actually, that's not strictly correct. there's nothing stopping you from having the .so files for both of them installed but the symlink libgnutls.so.26 can only point to one of them so only one can be in use at a time.
Posted May 1, 2015 12:24 UTC (Fri)
by HelloWorld (guest, #56129)
[Link]
Posted May 1, 2015 12:30 UTC (Fri)
by cortana (subscriber, #24596)
[Link] (2 responses)
Please, there is absolutely no cause for this kind of abusive language
> you don't(
Nonetheless, I need to because I want to run two programs; one is broken by a bug in the newer version, and the other requires a new feature from the newer version.
"You don't need to do that" is the typical reason that drives users away from OS-provided package managers. Frequently users do, in fact, need to install multiple versions at the same time.
Posted May 1, 2015 18:52 UTC (Fri)
by dlang (guest, #313)
[Link] (1 responses)
you may be able to paper over this in some cases if the application authors statically link or do something like this. But eventually you will run into problems that you can't paper over like this and your only answer is to be that you need to run your two apps with incompatible requirements on different systems (one of those systems can be a VM on your desktop)
The same sort of thing can happen on Windows. The term DLL Hell came from this exact situation where different programs require different, incompatible versions of a single DLL.
Posted May 1, 2015 19:56 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Linux distros are still in the 'denial' phase.
Posted May 1, 2015 13:11 UTC (Fri)
by corbet (editor, #1)
[Link]
Posted May 1, 2015 0:08 UTC (Fri)
by flussence (guest, #85566)
[Link]
There are varying degrees of workarounds available in such a situation, however miserable-sounding and contrived it may be: ld.so(8) tricks, a chroot install of the broken software, full virtualisation, or possibly rubber-hose debugging of the offender.
Posted Apr 30, 2015 9:11 UTC (Thu)
by nicku (guest, #777)
[Link] (3 responses)
Posted Apr 30, 2015 19:50 UTC (Thu)
by HelloWorld (guest, #56129)
[Link]
Posted May 1, 2015 18:06 UTC (Fri)
by lsl (subscriber, #86508)
[Link] (1 responses)
5.18 perldelta:
Posted May 1, 2015 22:30 UTC (Fri)
by flussence (guest, #85566)
[Link]
The warnings are the least-worst solution here, it's a broken concept but they can't just pull the rug out from under people in a language that's supposed to be stable and predictable (like PHP did when they failed at implementing Unicode in 6.0).
Posted Apr 30, 2015 8:33 UTC (Thu)
by mjthayer (guest, #39183)
[Link]
I quite agree that there is a lot of room for improvement. I also have to say that we (VirtualBox) have less packaging effort supporting quite a wide range of Linux distributions with binaries and keeping things working (including kernel modules) than we do for the range of Windows versions we support. No, we do not do everything as nicely as we could. Yes, overall I think we make a pretty good job of it.
Posted Apr 27, 2015 17:56 UTC (Mon)
by zorro (subscriber, #45643)
[Link]
Posted Apr 27, 2015 12:01 UTC (Mon)
by jrigg (guest, #30848)
[Link] (43 responses)
You appear to be ignoring the fact that making a large and complex application run on many different Linux and *nix systems really is difficult if it needs specific features that don't exist in the library versions in any particular distribution. Bundling libraries is sometimes the only practical solution.
Posted Apr 27, 2015 18:06 UTC (Mon)
by pboddie (guest, #50784)
[Link] (42 responses)
Posted Apr 28, 2015 11:50 UTC (Tue)
by NAR (subscriber, #1313)
[Link] (41 responses)
But what is the target platform? There's no such thing as desktop (or for that matter, server) Linux, there's only Ubuntu, Fedora, Debian, OpenSuSE, Gentoo, ArchLinux, Ubuntu LTS, CentOS, RHEL, etc. A couple of these have new versions every 6-8 months, so the whole integration and testing has to be done over and over. Are you surprised developers are not interested in doing this? Do you think it's realistic to expect that an application developer keeps around and maintains(!) 8-10 machines (virtual or real, doesn't matter) to do the integration? And trusting the undermanpowered distributions doesn't seem to be a good idea either and doesn't work with proprietary code.
What I see in practice is that developers target one single version of one single distribution, do the integration and testing there. Eventually this punts the problem to the user who might not be able to run application X and application Y on the same OS, because application X runs only on distribution Z version N and application Y runs only on distribution W version M.
Posted Apr 28, 2015 13:46 UTC (Tue)
by cas (guest, #52554)
[Link] (40 responses)
if you're keen, you might also target Arch and/or Gentoo.
if the european market is important to you, then maybe opensuse too - although debian and fedora will cover most of that.
also, as long as you don't do stupid things that make the OS package maintainers job a PITA, like bundling libs and hard-coding paths and other stuff because that's what works on your personal system, the packaging is likely to be done and maintained for you by the distro maintainers. packaging and system integration is what they do, and it's what they're good at.
if you're talking about commercial or especially proprietary software, then who cares? that shit simply isn't important or relevant. outside of a handful of specialist niches that haven't been commoditised yet (the largest and most significant being games - *NOT* business software), proprietary software just isn't needed on free software operating systems. the companies that sell it might wish otherwise, but free software users just don't need it.
Posted Apr 28, 2015 16:41 UTC (Tue)
by nye (subscriber, #51576)
[Link] (35 responses)
When you say things like this, it makes you sound like you're so obviously insane that everything you ever say can be safely dismissed out of hand.
Posted Apr 28, 2015 17:56 UTC (Tue)
by pizza (subscriber, #46)
[Link]
> When you say things like this, it makes you sound like you're so obviously insane that everything you ever say can be safely dismissed out of hand.
Here's the thing -- His position doesn't represent all possible options, it doesn't make it any less valid.
Debian, as a whole, does not consider proprietary software as terribly important one way or another. F/OSS is their primary target, and the decisions they make are primarily judged on the basis of the how F/OSS benefits. If proprietary stuff benefits from improvements targeted elsewhere, great!
Now it so happens that many of the improvements that would make life easier for proprietary stuff will also benefit F/OSS too (eg symbol versioning for libraries, better platform definitions) but you're not going to get much traction at all when you advocate for something that creates a ton of work but yields little benefit to, or will actually harm, F/OSS.
Posted Apr 28, 2015 22:09 UTC (Tue)
by cas (guest, #52554)
[Link] (33 responses)
since you're so wise and knowledgable, tell me the name of even *one* commercial software package that I, as a desktop linux user, actually need.
I can't think of any.
Sure, I play games (and even have a win7 box for it which i use for *nothing* else - i don't even buy games from it, i buy steam games from my linux browser because no windows box is ever getting my credit card details typed in on it, not even one i maintain) but a) steam, gog, humble bundle, etc for linux are even providing many games that run natively on linux and b) i don't actually *need* to buy games, certainly not any specific game - there are many that I boycott because of 3rd-party DRM or 3rd-party registration requirements or because the companies behind it are arseholes.
so, yeah, tell me one that I actually need.
Posted Apr 28, 2015 22:32 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (21 responses)
Posted Apr 28, 2015 22:55 UTC (Tue)
by cas (guest, #52554)
[Link] (20 responses)
2. i know lots of free software users who do not use and do not need to use proprietary software, with many of them using even less than i do because they either don't play games at all or don't play proprietary games. i do not claim that this applies to everyone in the world, but the indifference to proprietary software is clearly present in a lot more than just me.
i do, however, claim that most of the people who think they need proprietary software would be more than adequately served by free software if they tried it, even if they didn't give a damn about the ethical side of the free software argument. most computer users do not have specialist needs or require niche software, most of them use commoditised software like browsers, word processors, spreadsheets, accounting software, file managers and other utilities, and the like - all of which have excellent free software options.
Posted Apr 29, 2015 0:23 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (18 responses)
Posted Apr 29, 2015 1:02 UTC (Wed)
by pizza (subscriber, #46)
[Link]
For sake of argument I'll assume you meant *preparing* your taxes rather than the rather trivial filing process - But in either case you can open up a web browser of your choice at the IRS's Free File Alliance partner list, which includes several pure browser-based options from the usual assortment of big names.
I've used one of them for the past four or five years now, and my last filing consisted of more than a dozen forms and schedules.
Posted Apr 29, 2015 1:12 UTC (Wed)
by cas (guest, #52554)
[Link] (13 responses)
many people in many countries use GNUcash to keep track of finances. It can export data in a format which can be used by their accountant to file tax returns. Others use KMyMoney or LedgerSMB or one of several other alternatives. I don't personally use any of them so I have no idea which software is best for particular use cases.
In Australia, the Australian Taxation Office's etax software (free but not open source) can be run with wine. the ATO is the rough .au equivalent of the US IRS. i don't use this software either. my tax requirements are so simple that screwing around with such software is more hassle than just doing it myself. i have far more important things to do with my time than learning the quirks of some single-use software.
btw, i'm not an accountant or a tax specialist in any country so you're really better off asking your accountant questions like that rather than some random guy on the internet.
personally, i don't see that software which gets used once per year is a compelling reason to choose a particular operating system - especially when most such software for windows will run perfectly well under wine. in fact, i believe that running windows just for accounting purposes is a security disaster waiting to happen - microsoft windows can't be trusted to safely store such personally-identifying information.
Posted Apr 29, 2015 1:48 UTC (Wed)
by torquay (guest, #92428)
[Link] (7 responses)
Please. This is essentially an apologist position, claiming that wanting to do X on Linux doesn't matter because you "shouldn't" do X, for arbitrary value of X. This is also a freedom limiting argument.
I believe the point Cyberax is trying to make is that no vendor is willing to put in the money and effort do write software to do X (open source or proprietary), partly due to the fragmentation and instability within the Linux ecosystem.
This in turn leads to a chicken-n-egg problem: no software on "Linux", so no market share, so no incentive to write the software.
Posted Apr 29, 2015 2:46 UTC (Wed)
by cas (guest, #52554)
[Link] (6 responses)
stop misrepresenting what i said. i *never* said that 'wanting to do X on Linux doesn't matter because you "shouldn't" do X' or anything like it. I said that proprietary software on linux is irrelevant to me and to many other people because we don't use it and have no need for it. > I believe the point Cyberax is trying to make is that [...] no. cyberax's point is that linux is a shitty operating system and that nobody uses it as a desktop OS. both of these claims are demonstrably false. it's clear from every comment he's made that he has a chip on his shoulder about free software - perhaps because he's a wannabe commercial software developer pissed off because nobody who uses linux is at all interested in his crappy proprietary software. that stuff sells and makes a fortune on windows and on mac - partly because things that linux users take for granted as being included with the OS are not included with proprietary systems, and partly because win & mac users have internalised the belief that only software you pay for is any good. either that or he's some kind of trolling astro-turfer, paid to spread the idea that linux is no good as a desktop OS. it seems very suss to me that, on a thread on LWN about a new release of debian that there are 3 or 4 people that vehemently push that meme - if linux is so bad then what the hell are they doing wasting their time on a linux news site? surely their time would be better spent on fora devoted to mac or windows or whetever it is that they use? in any case, nothing that cyberax has said is of any value. quite the contrary. his prejudices, misinformations, and outright lies are self-evident.
Posted Apr 29, 2015 3:01 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
And this in turn means that Linux is not an option for many, many customers. Majority of them, as evidenced by the market share.
Please note, that I don't say that Linux can't be used by _anyone_. It's demonstrably not true - lots of people use it.
> perhaps because he's a wannabe commercial software developer pissed off because nobody who uses linux is at all interested in his crappy proprietary software
And most of my bitter experience with _desktop_ Linux comes from owning a company that tried to migrate companies from Windows to Linux (back at the beginning of the Windows Vista era).
Posted Apr 29, 2015 3:54 UTC (Wed)
by dlang (guest, #313)
[Link] (4 responses)
Well, I see a lot of third party software for Linux. I work in the security department in what has otherwise been an all Windows shop. Most of the good security tools are Linux only. Many other tools are available on Windows as well as Linux, but even the Corp IT folks are interested in migrating them to Linux because they just work better.
Yes, there are gaps, and some of the gaps are really annoying (top tier vendors that make their stuff work on Android but tell Linux folks "run it on wine" or "tough luck" are a group I find especially annoying) Netflix is in this category for example.
Now, if you claim that there is a large body of developers who don't bother to port their desktop systems to Linux, I'll agree with you. A very high percentage of those same developers refuse to develop for Windows/Mac (they do one, but not the other). But I disagree with your conclusions as to the reasons.
Posted Apr 29, 2015 4:20 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
And the core reasons are the same - developers really need a reliable base on which to build. Android provides it, Microsoft provides it, but the classic Linux desktop doesn't.
Even the server-side Linux slowly converges into something more-or-less standard.
Posted Apr 29, 2015 4:39 UTC (Wed)
by dlang (guest, #313)
[Link] (2 responses)
you claim that if the Linux desktop only standardized on one set of libraries it would get everyone porting their software to it ignores the fact that Windows developers don't port their software to Macs, and Mac developers don't port their software to Windows (except for a vanishingly small percentage, not _that_ much higher than the percentage that port their software to Linux)
Posted Apr 29, 2015 6:08 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
But that's not the point. The point is that there _is_ a huge ecosystem of third-party products for both Windows and Mac OS X. There's nothing like it for desktop Linux.
Posted Apr 29, 2015 6:31 UTC (Wed)
by cas (guest, #52554)
[Link]
there's no need to pay for norton ghost when i can use clonezilla, no need to pay for a partition management tool, no need to pay for a compression or archiving tool, no need to pay for anti-virus or firewall products, no need to pay for word processors or spreadsheets or databases. no need to pay for thousands of kinds of software that make up the hugely profitable markets for windows and mac developers.
now, before you say that some of these programs are difficult to use or inferior to some of the proprietary offerings, in some cases that's true. in other cases, it isn't - in fact, it's the other way around...the free software options are far superior and/or easier to use than the proprietary.
so, yes, in some cases it's true that free software is crap. in other cases, it's equally true that proprietary software is crap - and *all* proprietary software has the anti-feature of being developed for the manufacturer's benefit rather than the user's benefit with things like DRM and proprietary file formats and other customer lockin methods, and multiple versions with different features to artificially create market segmentation (e.g. if you want feature X then you have to pay more for the profesional version)...plus, of course, the inability of users to modify or fix the proprietary software they've paid for.
Posted Apr 29, 2015 3:37 UTC (Wed)
by neilbrown (subscriber, #359)
[Link] (4 responses)
Can it? It never worked for me - the crypto connections back to the mother ship never seemed to get off the ground.
Is there some trick to making it work?
Posted Apr 29, 2015 3:51 UTC (Wed)
by cas (guest, #52554)
[Link] (3 responses)
my comments were based on what i read on the ATO's own etax web page (which says that, although it is unsupported on linux some people have successfully run it using wine) and on various posts on the whirlpool.net.au forums - consensus there seems to be that you need to use winetricks for msxml4 and ie7 before trying to install etax.
try a google search for "etax linux site:http://forums.whirlpool.net.au"
Posted Apr 29, 2015 6:10 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Apr 29, 2015 6:36 UTC (Wed)
by cas (guest, #52554)
[Link] (1 responses)
that makes as much sense as everything else you've said.
Posted Apr 29, 2015 20:56 UTC (Wed)
by bronson (subscriber, #4806)
[Link]
You're grasping at straws.
Posted Apr 29, 2015 14:55 UTC (Wed)
by spaetz (guest, #32870)
[Link]
I don't know about you, but I open the java-based tax software from http://www.steueramt.zh.ch/privatetax and start filing the same way that others do. In other countries there are web-based services that let you do that. It sucks if your country does not offer anything like that, true.
Posted Apr 29, 2015 22:22 UTC (Wed)
by cesarb (subscriber, #6266)
[Link] (1 responses)
You download the official tax filing software, which is written in Java, from the government website.
(You didn't specify the country.)
Posted Apr 30, 2015 0:22 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Apr 29, 2015 10:06 UTC (Wed)
by HelloWorld (guest, #56129)
[Link]
Posted Apr 29, 2015 11:07 UTC (Wed)
by nye (subscriber, #51576)
[Link] (10 responses)
Nobody said anything of the sort. This is exactly the kind of ridiculous strawman that I was expecting you to use to prove my point.
Specifically, as I quoted, you claimed that commercial software is only of any relevance in a "handful of specialist niches", when what you really mean is "I personally don't need it". The stated claim is obviously completely indefensible; anyone trying to make it is ipso facto living in a fantasy. When somebody is living in a fantasy, anything they say must be strongly distrusted unless there's some other way to know whether or not it applies to our world.
Posted Apr 29, 2015 21:36 UTC (Wed)
by cas (guest, #52554)
[Link] (9 responses)
some people may want particular brands of commercial software, but want is not the same as need.
if you disagree, name even one kind of proprietary commodity software that is actually *needed* by free software users. i can name lots of specialist niche programs that some users need, but not one commodity program.
you're the one making the extraordinary claim that proprietary software is needed. by rights, you should offer extraordinary proof. i'll settle for any proof.
to make it easier for you, you can name a particular software package or a generic type of software. your choice.
Posted Apr 29, 2015 22:52 UTC (Wed)
by bronson (subscriber, #4806)
[Link] (7 responses)
Name even one piece of weaponry actually needed by pacifists. Name one piece of free software needed to pass your MCSE. Name even one piece of clothing needed by nudists.
You worded your statement like it's a question. It's sophistry, and it's getting tiring.
Posted Apr 29, 2015 23:09 UTC (Wed)
by cas (guest, #52554)
[Link] (6 responses)
thanks for restating my point so succinctly. i take it that you agree that free software users don't need commodity proprietary software?
> Name even one piece of clothing needed by nudists.
shoes. and other items depending on the weather.
> You worded your statement like it's a question. It's sophistry,
no, it was a legitimate question. and one that hasn't been answered yet. all you've managed to do is to concede my point. the fact that neither you nor anyone else so far has been able to answer doesn't permit you to make such a lame attempt to dismiss my line of argument.
Posted Apr 29, 2015 23:50 UTC (Wed)
by bronson (subscriber, #4806)
[Link] (5 responses)
Obviously not. I take it that you agree that you're here just to make noise?
I wrote examples of inconsistent questions (well, maybe the MCSE one is OK, I don't know). Just like your question is inconsistent.
How old was Edison? What is the difference between a pigeon? Give me a correct answer or admit that I am right!
What are you hoping to accomplish here?
Posted Apr 30, 2015 0:04 UTC (Thu)
by cas (guest, #52554)
[Link] (4 responses)
make a point. you're obviously here to waste everyone's time by demostrating your idiocy.
i'm not going to waste any more of my time on you. but before i go, i'll just point out that in an argument about whether proprietary software is needed by free software users, asking someone to name even one piece of necessary proprietary software is an absolutely relevant question. your asinine attempt to categorise that question as irrelevant reeks of failure.
bye. HAND. GBTYMBAHANW.
Posted Apr 30, 2015 0:54 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (3 responses)
Let's assume you worded your question so that it can be answered. Maybe, "name even one kind of proprietary commodity software that provides features that you need that aren't provided by free software."
For me, that's easy: Altium. One day Kicad could catch up but it's going to take years, probably decades. I haven't even managed to get a stable build on my laptop yet and, believe me, I've spent days trying (would love to be able to delete this Windows VM). Also LTSpice.
Other people will say Autocad. Or SolidWorks. Or the thousands of other software products where free equivalents aren't even close.
But I expect you know this and that's why you're wording your question so strangely.
Posted May 4, 2015 2:19 UTC (Mon)
by jschrod (subscriber, #1646)
[Link] (2 responses)
Well, then I should answer as well.
> Let's assume you worded your question so that it can be answered. Maybe,
Yes, and from context it was clear that he meant mainstream usage of computers, not niche segments.
> For me, that's easy: Altium. One day Kicad [...]
Don't even know what that is. Google tells me it "provides PC-based electronics design software for engineers". You're sure that this is a mainstream usage? That most - or let's say, more than two - of my neighbours will think the availability of electronics design software for engineers is important? Questionable, to say the least.
> Other people will say Autocad. Or SolidWorks.
Again, hmm. I have had hundreds of clients where I introduced new IT processes in the last few years, together with new applications and processes. None of them use Autocad or SolidWorks, btw. If there are proprietary applications that are ingrained and "shall not be replaced", it's mostly a matter of work processes and not of functionality. But the "cloud movement" and its push for standardization takes care of that. Commodity software is our future; and that means open source software.
Looking at my clients, they run their business with open source software. Every time they replace a proprietary solution they replace their dependency on a company that might go out of business or is prone to do so. They actively encourage that. It's a sound business decision. Short term gains by some applications are not worth the dependency on their producers, that's the mind set I encounter every day.
Btw, our clients are from finance, logistics, and telcos. Larger companies; our smallest one has 20,000 employees. SOHO shops and smaller companies may have differing attitudes, but that will change over time, too.
Posted May 4, 2015 12:14 UTC (Mon)
by MrWim (subscriber, #47432)
[Link] (1 responses)
I worry that this isn't what's been happening. One could make the argument that at this point the only mainstream program is the web-browser. I see a lot of people that tablets are sufficient and this is because you spend 90% of your time in the web-browser, or in apps which are just views of web-pages anyway. So I agree that the free software available on desktop PCs is better than it ever was, and that it's easier to run a free desktop than it ever was, but I think maybe that's because the battle is being fought elsewhere. So I think the trend has been a move toward non-free web-apps, which provide you even fewer freedoms and control over your data than traditional 1990s style proprietary software. I think there's a parallel to the old saying that each user only uses 10% of the features of a word-processor, but each one uses a different 10%. I think the value in desktop computers is that they are general-purpose. Everyone might need mainstream software like word-processors, but equally most people who would choose to use a desktop PC belongs to a niche, just not the same one as each other. So, even with all the "non-niche" software provided by free software, you still don't have a system that will fulfil the needs of 90% of the population.
Posted May 4, 2015 13:34 UTC (Mon)
by pizza (subscriber, #46)
[Link]
Unfortunately, I agree.. but the underlying problem is much deeper than that. We are/were so focused on "software" that we basically missed the point of said software -- it provides/fulfills a service.
Webapps etc don't provide "software", they provide "services", and we can't compete with a service by continuing to provide software.
Posted Apr 30, 2015 11:27 UTC (Thu)
by HelloWorld (guest, #56129)
[Link]
Posted Apr 29, 2015 9:50 UTC (Wed)
by NAR (subscriber, #1313)
[Link] (3 responses)
No, you can't skip the integration and testing on all platforms. For example we had a dependency that linked to a specific version of openssl. New SuSE version came around, of course didn't have the same version of openssl and the program didn't work. Of course, it was detected by the user, not us, because we haven't migrated to the new SuSE version. Had similar problems with libreadline. And the glibc had different bugs too. The whole point of integration testing to find these anomalies. And due to the ridiculously fragmented landscape one has to do lot of these. Or simply don't care, don't spend resources on the bazillion distributions, just tell the user that use only a specific version of specific distribution.
Posted Apr 29, 2015 12:53 UTC (Wed)
by dgm (subscriber, #49227)
[Link] (2 responses)
I think the "fragmented landscape" exists basically because of the lack of pressure to defragment it.
Posted Apr 30, 2015 19:03 UTC (Thu)
by ms_43 (subscriber, #99293)
[Link] (1 responses)
Posted May 7, 2015 16:46 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Apr 30, 2015 8:23 UTC (Thu)
by mjthayer (guest, #39183)
[Link] (1 responses)
Actually even within a single process and for any given library you can decide whether to bundle it, link to it dynamically or even shell out to a command line wrapper (e.g. openssl(1)). That lets you balance things like historical ABI stability and frequency of security updates. You still have to know your dependencies well of course, especially for anything you link to dynamically, otherwise you might find yourself in fun situations like a dynamic dependency pulling in a (different) dynamic version of something you have linked to statically.
Posted Apr 30, 2015 8:34 UTC (Thu)
by mjthayer (guest, #39183)
[Link]
I forgot to mention dynamically loaded plug-ins, potentially with their own unstable ABI.
Posted Apr 27, 2015 7:32 UTC (Mon)
by cortana (subscriber, #24596)
[Link] (7 responses)
Posted Apr 27, 2015 9:11 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
In the first part of his post this guy simply complains that he's become obsolete and can't keep up with build systems a little bit more modern than autoconf. Cry me a river.
Building software from source is complicated? Boo hoo! Had he been born yesterday? It has _never_ been as simple as typing 'make'.
And his example of a hard-to-build software is incoherent - Hadoop is trivially easy to build. The only non-trivial piece is its dependence on a specific version of protobuf - you have to install it separately.
In the second part he rants that the omnipowerful NSA can install backdoors into all those scary binary packages (BTW, Maven authenticates the downloaded packages). I guess he reads all the source code of all the packages he installs (except Hadoop, he can't build it).
Posted Apr 27, 2015 13:31 UTC (Mon)
by alfille (subscriber, #1631)
[Link] (4 responses)
I can't understand the distinction between a package and the -devel version. Basically it's the header files. Trivial file size. It would be easier (and avoid version mismatch) if the headers were included with all packages.
Second, most packaging systems want to make components as fragmented as possible. So you have the program, the data, the documentation, the library and the devel all separated. And then meta packages to wrap them all together.
I remember disks measured in megabytes. Space mattered. My phone can probably hold all of debian and it's packages. Or my camera. Or my USB thumb drive.
My point is that each individual component has a cost and the total cost goes up non-linearly. We should be consolidating as much as possible, and only split truly disjoint pieces or very large and optional parts.
Posted Apr 27, 2015 15:00 UTC (Mon)
by cortana (subscriber, #24596)
[Link] (1 responses)
In the case of Debian, libfoo-dev contains both headers and the static library. And on my system, with a mere handful of -dev packages installed, /usr/include comes to 46 MiB. I'd rather not eat that for each of the dozens of containers I have on my system...
Posted Apr 27, 2015 17:54 UTC (Mon)
by amck (subscriber, #7270)
[Link]
> I can't understand the distinction between a package and the -devel version. Basically it's the header files. Trivial file size.
More than that. You can have multiple versions of a library, but typically only one set of header files.
Take a library, e.g. Netcdf in Debian wheezy. It was upgraded, so the lib package provides libnetcdf.so.6 was replaced by one that is incompatible, but ships libnetcdf.so.7.
Posted Apr 27, 2015 15:50 UTC (Mon)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
Posted Apr 27, 2015 16:50 UTC (Mon)
by alfille (subscriber, #1631)
[Link]
As for containers, I presume they are optimized by hand (the effort is amortized over many copies). If nothing else, a "--lean" option in the package manager would make the most sense, so the optimization step would be trivial.
Again, I think packaging is a victim of legacy optimization. We now deal with a large package set with many "parts" per package. Stripping out data from a "meta" package is easy, and easily automated. Gathering all the parts is harder, and often requires trial and error.
Posted Apr 30, 2015 0:59 UTC (Thu)
by bronson (subscriber, #4806)
[Link]
That's funny and true.
Posted Apr 27, 2015 3:42 UTC (Mon)
by bandrami (guest, #94229)
[Link] (1 responses)
Sure. Link statically, like a sensible person, and you're ABI-compatible as long as you don't use setup(2), query_module(2), pread64(2), perfctr(2), nfsservctl(2), get_kernel_syms(2), free_hugepages(2), or create_module(2) (and you probably don't use any of those).
Posted Apr 29, 2015 12:02 UTC (Wed)
by foom (subscriber, #14868)
[Link]
Posted Apr 26, 2015 22:35 UTC (Sun)
by smoogen (subscriber, #97)
[Link] (2 responses)
Posted Apr 27, 2015 12:51 UTC (Mon)
by jzb (editor, #7867)
[Link]
Posted Apr 28, 2015 19:11 UTC (Tue)
by boog (subscriber, #30882)
[Link]
Posted Apr 29, 2015 22:14 UTC (Wed)
by faheem (guest, #47574)
[Link]
Debian 8 "Jessie" released
Debian 8 "Jessie" released
With this broad selection of packages ... Debian once again stays true to its goal of being the universal operating system.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
The interpreted languages are far worse in how much they subject users to dependency hell.
API breaks
I happen to work on two RPM-based distributions. On one I get this result from a command:
API breaks
$ rpm -q -f `which imake`
xorg-x11-util-devel-7.4-1.15
on the other I get
$ rpm -q -f `which imake`
imake-1.0.2-11.el6.x86_64
Exactly what value do I get from packaging the very same software in two vastly different ways?
API breaks
Yum command has been deprecated, use dnf instead.
Using metadata from Mon Apr 27 13:13:16 2015 (1 day, 2:30:01 hours old)
Dependencies resolved.
=======================================================================
Package Arch Version Repository Size
=======================================================================
Installing:
imake x86_64 1.0.7-4.fc22 fedora 263 k
=======================================================================
Install 1 Package
Installed size: 1.2 M
Is this ok [y/N]:
API breaks
API breaks
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Aren't all stable releases intended to be LTS? Debian 8 "Jessie" released
Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Finding a common version of any lib supported by all of them is downright *impossible*. Sometimes even they do not include the same libraries.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Are you seriously that naïve? Most commercial products require professional and timely support. If you depend on a non-affiliated packager then it's pretty much impossible to do it.
For example, like libffi? You _have_ to use it if you want to interoperate with lua or Python. Yet there's no single version of libffi that is available in CentOS 6, CentOS 7 and Ubuntu 12.04.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Actually, no. Most cluefull companies simply don't bother with Linux. Too much drama and stress for little gain.
Dude, have you seen all those Linux desktops in all computer stores with queues of people waiting for days for a chance to buy one?
Debian 8 "Jessie" released
There are simply no compelling reasons for the actual real-life users to actually install a Linux desktop.
OK. And? If users want a free software desktop with lots of stuff ready to go out of the box they can choose Linux, if users want a proprietary system with near universal compatibility they can run Windows, and if they want proprietary, middling compatibility, but really pretty they can run OS X. And that's fine.
Debian 8 "Jessie" released
There's no need to make the Linux desktop a first class friendly environment for proprietary software
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
There's no need to make the Linux desktop a first class friendly environment for proprietary software, that need is already well served. It's a different system for a different niche, and for the equally real if not equally numerous users that it suits, it's working pretty well.
Any why not? I am a Linux desktop user, I use it for development as well as what normal users use it for. I will gladly pay for proprietary software if it runs well on my system and there is no good free equivalent (e.g. funny to say but a good simple text editor!). The problem is some eccentric open source programmers also have a world view about software freedom that they want to force down users, they do not want to use GNU/Herd either because well its too limiting even for them.
Debian 8 "Jessie" released
I see people choosing Mac OS X. It runs most of UNIX tools and is actually stable enough to use.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
>[citation needed]
Easy.
http://en.wikipedia.org/w/index.php?title=Usage_share_of_...
http://en.wikipedia.org/wiki/Usage_share_of_operating_sys...
Exactly.
Volunteers can continue their slide into irrelevance if it's their choice. It's a free country.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
use Inline 'Lua';
use Inline 'Python';
say "The answer to life, the universe and everything is ", answer(part(), 7);
__Lua__
function answer (a, b)
return a * b
end
__Python__
def part():
return 6
Debian 8 "Jessie" released
- Microchip (MPLAB-X IDE and XC compiler, including PIC programmers hardware management)
- Xilinx (ISE, an IDE to program FPGA)
- Cadsoft (Eagle, a PCB-design suite)
- Altera (Quartus II, an IDE to program FPGA)
- Oracle
- Steam (Both Steam game distribution platform and games distributed under Steam)
Of course it's *possible* to do it, nobody denied that. But that doesn't change the fact that making binaries for Linux desktop applications is a major fucking pain in the ass. And people like you who deny this simple truth rather than looking for a solution are part of the problem.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Dude, you should really take a reading class.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
* Limit the number of packaged applications to the barely essential for an OS tasks: installation, running, maintenance, maybe development (this is Open Source after all). All else not part of the core OS is Application Space (analogue to User Space for the kernel). Those can still be packaged, but as a separate effort (with separate release cycles).
* Pick libraries and daemons wisely, avoid duplication of function. Ensure that binary compatibility is maintained by working closely with library developers. Never, ever, break Application Space. If some library provider gets too adventurous, fork.
* Document all the choices. Make them as coherent and understandable as possible. If it's difficult to explain a decision, maybe it's not a wise one.
* Make all this communication public and accessible. There are parts of Open Source community that can help in making this information reach the public at large (lwn is a prime example of this).
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
> You will finish with an extra libraries layer on those OS but maybe
> it is a reasonable way to solve this problem.
Debian 8 "Jessie" released
Yeah, except that it's not. Libraries do break compatibility without changing the SONAME, and that problem doesn't go away by telling the developers of said libraries how lazy they are and to flip burgers instead. In fact that only serves to show that you're both out of touch with reality and a douchebag.
Bullshit. Application developers want users to be able to run their software *today*. They don't want them to wait until the next release of the distro which includes the library. They don't want to force them to upgrade if they're running on RHEL 5 or Ubuntu 12.04, they just want stuff to work.
“Insanity: doing the same thing over and over again and expecting different results.”
“We cannot solve our problems with the same thinking we used when we created them.”
Debian 8 "Jessie" released
> changing the SONAME, and that problem doesn't go away by telling the
> developers of said libraries how lazy they are and to flip burgers>
> instead.
> *today*.
> and deny the very real problems with it.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
That library update consisted of a single isolated change andere wer die all the QA that was necessary.
We don't fear it, but it would be foolish not to be aware of the possible consequences of failures.
In short: you don't know me, my employer, our project, the circumstances, our customers or anything else. You have no idea what you're talking about so just shut the f*ck up, douchebag.
Shipping bugfixes fast isn't a bad practice, dumbass.
OK, you've triggered my "please stop this" limit yet again. Please stop this.
Please
Debian 8 "Jessie" released
Oops, I should find a way to disable autocorrect when using my phone. It was meant to read “…isolated change and we did all the QA…”
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
> at the same time?
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Except that Microsoft acknowledged this problem and developed a solution: side-by-side installation of global libraries. So there's no more DLL hell on Windows.
Please calm down, this isn't a whole lot of fun. Surely you can make your point without being abusive?
You too
Debian 8 "Jessie" released
Debian 8 "Jessie" released
(*): well, Perl fucked up recently, but in general they do ok.
I write Perl for a living, but don't know this; reference please?
Debian 8 "Jessie" released
Debian 8 "Jessie" released
http://search.cpan.org/dist/perl-5.18.0/pod/perldelta.pod
Debian 8 "Jessie" released
Debian 8 "Jessie" released
>Finding a common version of any lib supported by all of them is downright *impossible*. Sometimes even they do not include the same libraries.
Debian 8 "Jessie" released
except for the handful that don't - they're usually by developers who insist that their application is special...so special that it must ignore the system(s) it is running on, do things its own special way, and have its own special bundled versions of common libraries.
So what?
because working WITH the operating system or WITH the developers of the libs is too much work
Yes, it is.
it's far easier to just ignore them both and use either specific (typically either ancient or pre-release bleeding edge) versions of libraries or hacked up versions of them (without bothering to submit patches upstream)
Yes, it is. What is your point?
Debian 8 "Jessie" released
Debian 8 "Jessie" released
the developers aren't interested in testing and integrating an application with the target platform.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
What is insane is not your real life experience but assuming that it carries over to everybody else.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Yes, it's a shitty operating system for third-party vendors. So that's why there's so little third-party software for Linux.
Nope. We sell Linux-only software and services now.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
I think the reasons for crappy Windows security tools are pretty much the same - it's way too complicated to do stuff like direct disk manipulation and/or network filtering. Mostly because Microsoft never really bothered with them - they actually have no problem telling customers to use Linux or Cisco routers instead of Windows Servers.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
And last year's didn't even get that far, though I don't recall the details.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Of course not, that's the point. Your question was meaningless to begin with.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
> > *needed* by free software users
>
> Name even one piece of weaponry actually needed by pacifists
> and it's getting tiring.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
> "name even one kind of proprietary commodity software that provides
> features that you need that aren't provided by free software."
Debian 8 "Jessie" released
Commodity software is our future; and that means open source software.
Don't even know what that is. Google tells me it "provides PC-based electronics design software for engineers". You're sure that this is a mainstream usage? That most - or let's say, more than two - of my neighbours will think the availability of electronics design software for engineers is important? Questionable, to say the least.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
One doesn't need a computer at all as evidenced by countless people all over the world. What's your point?
you really only have to target two
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
No thanks.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
So if I have an application that needs libnetcdf.so.6, I can pin that library and it will not be removed on upgrade.
But the /usr/include/netcdf/* files have changed, so only 1 copy can be present. Hence the split.
If the architecture-independent data and documentation files are included in the main package for a program, then you have N (where N = number of supported architectures) copies of that data in the distribution's archive instead of just one. Across large numbers of packages, that incurs a significant cost of its own.
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released
Debian 8 "Jessie" released