Viestit

1

Multimedia ja grafiikka / Vs: Näytä työpöytäsi

« : 26.06.13 - klo:01.04 »

Arch Linux & KDE
Helium & KAwOken

2

Yleistä keskustelua / Vs: MATE-työpöytää tarjolla useille distroille

« : 16.09.12 - klo:00.43 »

Sabayon 10 tulee kanssa MATE-työpöytä.

3

Muut käyttöjärjestelmät ja Linux-jakelut / Vs: Arch Linux

« : 22.08.12 - klo:18.10 »

Minusta on vaan jotenkin vastemielistä ladata joku asennus CD ja toivoa, etä X käynnistyy jotenkin järkevällä tavalla jotta asennus onnistuisi. Näytönohjain ja tuki siihen hyvin usein pullonkaulana.

Arch Linuxin asennus tapahtuu komentorivityökalujen sekä asennusskirpien avulla, mitään graafista asennusta ei voi edes tehdä. Ohjeet löytyvät sekä täältä (nopeampi) että täältä (helpompi).

Pitääkö siinä ladata joku asennus CD vai onnistuisiko asennus Gentoo tyyliin ilman asennusmediaa.

Molemmat on mahdollisia. Ohjeet[/quote] jälkimmäiseen ovat vain vanhentuneet, luultavasti tapahtuu hyvin samaan tapaan kuin Gentoossa.

4

Muut käyttöjärjestelmät ja Linux-jakelut / Vs: Arch Linux

« : 21.08.12 - klo:21.25 »

Timing:
We don't have a date yet, but we have a list of blockers (we need the next releases of util-linux and sysvinit at least, and we need full coverage of systemd service files for all packages that have rc scripts). So I guess the best I can say is "when it is ready". There is also the added wish to do it "as soon as possible" as it will make the packaging of the next versions of certain packages (gnome, polkit at least, but probably many others that I'm not aware of) much easier.
Transition:

We have tried to make this smooth.

0) The best approach is to first bring your rc.conf up-to-date according to the recommendations in "man rc.conf". It should essentially only contain your DAEMONS array (and a few other things, depending on your setup, see manpage for details). This will work both with initscripts and systemd so it is safe to do ahead of time, and make sure everything works as it should.

1) Install systemd, but you do not need to remove initscripts. You can now chose between the two at runtime (by adding init=/bin/systemd to your kernel commandline). If you do this systemd will keep respecting rc.conf and use rc scripts if systemd unit files can not be found.

2) Then you can move your system (hopefully seamlessly) over to a native systemd configuration: do (0) if you did not already, then find the corresponding systemd service file for every daemon in your daemons array and enable it using "systemctl enable <daemon>.service". Once this is done rc.conf is not needed by systemd at all anymore. Go through rc.local and rc.local.shutdown and turn them into service files (or, if you intend to keep them as they are, copy /usr/lib/systemd/system/rc-local{,.shutdown}.service to /etc/systemd/system/).

3) Once the above works ok, and you are confident that you don't need to revert to initscripts, then you can install systemd-sysvcompat, which will conflict (and hence remove) sysvinit+initscripts (and pacsave rc.conf, rc.local and rc.local.shutdown). You can now also remove init=/bin/systemd from your kernel commandline as /sbin/init will now be a symlink to systemd.
Benefits:

I have spent too much time arguing against the perceived deficiencies of systemd (such as: "it is not written in bash", "it was started by Lennart Poettering", "I don't like the (optional) on-disk format of the journal", "it uses dbus", "systemd's PID1 does more and is bigger than sysvinit's PID1", "I think there might be this other project that possibly is doing something similar. I don't really know anything about it, but I'm pretty sure it is better than systemd" and I'm sure there are many more). I strongly believe that 1) all of these perceived deficiencies are not deficiencies, but are actually benefits 2) even if I'm wrong, these things are not hugely important. So, with that out of the way: let's ignore all of those old boring arguments and I'll outline a few things that I find awesome about systemd, and why I think we should all be very excited about soon being able to use it. In no particular order:

0) it is hotplug capable: systemd assumes that all resources may appear and dissapear at any time. If you plug in your external harddrive after systemd has booted, it will be fsck'ed and mounted correctly. This is unlike initscripts which relies on all disks being enumerated and ready when it starts fsck, and then it relies on fsck of all disks being finished before it starts mounting any of them. Hotplug is important, not only because it is convenient to be able to insert/remove hardware while the system is running, but also because that's how the linux kernel does boot: every device appears to be "hotplugged" as the kernel becomes aware of it, so with a very fast boot we can no longer assume that all devices are ready and waiting for us when we need them (even if they were plugged in when the computer started). In reality this is often not a problem, but if you ever had your rootfs on an external USB harddrive you might have experienced problems (and as things become faster and faster more problems like this will crop up).

1) we can know the state of the system: systemd keeps track of all daemons, and all processes that are started, and who owns what, and when something fails, etc. Also, using the (awesome) journal all syslog() entries and writes to stdout/stderr by all processes are captured by systemd. These are stored with enough meta-data so that you can very easily retrieve say "all entries from a certain service/binary/pid" or "all entries written by the kernel regarding a given device", etc. In addition to logging this information, and showing it to you, systemd will allow you to specify (easily) what to do in a wide range of possible error-scenarios: "a service shuts down normally/with an error/ on a signa" or "a service has not sent its watchdog signal in the designated time" or "a service has shutdown with an error 10 times in the last half hour". The recent addition of hardware watchdog support also allows you to say "restart the machine if systemd itself is not responding".

2) it is modular: all of what is now rc.sysinit is split out into many independent services, each of which is well documented and easy to understand. I.e., if you don't like how  systemd e.g. does it's fstab handling, then you can write your own little helper (in bash if you wish) to replace the official one. Doing this in the old initscripts is much harder because 1) it is not so clear which parts of rc.sysinit are dependent on eachother 2) any changes you do you'll have to merge on every update.

3) it allows dbus/udev to go back to doing the task they are meant to do: both udev and dbus are currently (mis)-used to start daemons/long-running services on demand. In the case of dbus this is by design, but in the case of udev it is not. Either way, it is not what those daemons were built to do, so in keeping with the UNIX principle of one task per daemon, it is great that we can now let systemd (whose job it is to manage daemons) take this over. That is, udev and dbus can both signal systemd to start a certain daemon, and it will behave like if it was started in any other way (you have the logs, status etc). One problem that this solves is the inherent race-condition in some daemons (I think bluetoothd was guilty of this at some point) allowing both being started as soon as possible on boot (say by putting it in DAEMONS), and to be started on-demand by dbus. Systemd makes sure that both these things can happen, and if they do happen at the same time you will only end up with one instance of the daemon as expected.

4) we can reduce the number of explicit ordering dependencies between daemons (this might require changes to the daemons in question): using socket activation, automounting and dbus activation we are able to forget about stuff like "dbus must be running before we start avahi" or "yp-bind must be started after networkmanager". systemd can create sockets early on, before any daemons are started, and then pass the socket to the relevant daemon when it gets around to starting it. This means that anything can connect to anything else, without caring about whether or not the other daemon has finished starting yet. The kernel will simply buffer the requests whilst we wait and deliver them when it can. Notice that this does not actually remove any dependencies (so if there are circular deps, they will still be there), but it means we no longer have to specify them, nor worry about races between them.

5) we get a lot of security/sandboxing features for free: you can simply add some configuration options to the unit files in question to isolate them from the system in various ways. This was of course also possible before, but it required you to write lots of boilerplate code in every rc script, and this kind of things are very error prone, and best reviewed by people who know about this stuff.

6) systemd service files can (and hopefully will!) be written and distributed upstream: rather than every distro writing their own rc script (with their own set of trivial bugs and misunderstandings) the people who know the software the best (upstream) possibly with some input from the people who know the init system the best (systemd devs) can write "perfect" services that should just work everywhere. We have seen some of this already, and I think it is hugely benefitial. Even for distros who don't pick up systemd yet, this will allow them to at least have an idea oh how the software is meant to be initialized.

7) systemd is a cross-distro project: every major and many, many minor distros have had people contributing to systemd. last i heard even two debian devs have commit access to the repo, among many others. systemd upstream is very accommodating of different needs and different use-cases (as long as they are presented on technical grounds) and have been a pleasure to work with so far. We are getting the joint experience of a lot of people/projects who have worked on different init systems for a long time, I think this is one of the most important "features" one could have.

logind will finally deliver on what consolekit was supposed to do: we can now track user sessions and seats, assign permissions to resources on-the-fly etc. This should be the topic of a separate message, as it is too much to get into. Suffice it to say that I'm very happy that we are finally getting these features working as they should.

9) systemd is fast: Or is it really? Some claim there is no difference compared with initscripts, a very few claim it is slower, the vast majority claim it is a lot faster. I claim that I really don't care. The above points (which is just what I could think of at the top of my head, so not exhaustive by any means) would hopefully convince you that systemd is the right choice irrespective of its speed, and once you try it out you might be in for a pleasant surprise ;-)

@Arch Linux Forums

Oh, *so* many things. Here's just a few:

* Much more sophisticated structure. sysv gives you...services, and five runlevels, and that's about it. systemd gives you targets, which you can have as many of as you like, and which can be nested, and which can have dependencies.

* Oh yeah - it has dependencies. So services can be ordered properly and parallel started. upstart has this too, of course, but it still beats sysv.

* It has _far_ better monitoring / investigation / debug tools than sysv, though some people don't bother to actually look it up so just assume it's 'harder'. It's actually much easier to know what's going on with systemd. I can list out all active units (services, more or less) with 'systemctl'. List out all installed units, even inactive ones, with 'systemctl --all'. List out failed services with 'systemctl --failed' - so it's super easy to see if any services failed on start, and which ones. Get detailed info on a specific service - including its state, all its processes and sub-processes, and log output if journal is running - with 'systemctl status servicename'. There's way more than this, this is just scratching the surface.

* It has all sorts of cool capabilities for services. Literally tons of them, here's just a random sample. They can be set to auto-restart if they crash. You can have a service only start up if a given path exists, or a given path is a directory or a symlink, or if a specific kernel parameter is given, or if you're running in a VM (it even extends to specific *types* of VM). And you can invert all of those. You can set pre- and post- initialization commands for services. Services can set their own timeout values.

* It does socket activation of daemons. What this means is that you can have a service associated with a given daemon: the service is set to 'start' on boot, but it doesn't actually run the daemon until something tries to access it - either via a given TCP or UDP port, or via a specified dbus method. So you save system resources until the daemon is actually needed, and boot is faster.

* It has some really neat built-in charting tools: you can generate a bootchart right from systemd, and even cooler, you can generate a dependency map for the entire startup process, graphically depicting the relationships between services.

systemd is freaking awesome. I don't want to get into whether it's better than upstart, because I don't know anywhere near enough about upstart. But it absolutely does have all _sorts_ of improvements over sysv. I highly recommend you read about it; systemd has excellent documentation.

@Phoronix Forums

Siinä pari hyvää kirjoitusta systemd:stä, jos on vielä epävarma siitä miksi jakelu jakelun jälkeen siirtyy käyttämään sitä. Seuraavaksi on vuorossa Chakra.

5

Muut käyttöjärjestelmät ja Linux-jakelut / Vs: Arch Linux

« : 20.08.12 - klo:23.42 »

Arch Linux on nyt parempi kuin koskaan? Siksi että siinä on systemd? --  systemd on ollut saatavilla Gentooseen jo 2010. Mutta ei tietenkään ole oletuksena.

Jos haluaa kaiken irti systemd:stä, sitä täytyy tukea kunnolla. Muut init järjestelmät vaativat joidenkien pakettien patchaamista ja esimerkiksi Gnome riippuu joko systemd:stä tai ConsoleKitistä, jota ei enää kehitetä. Samalla säästytään turhalta pakettien pilkkomiselta (systemd-tools jne) ja ohjelmat toimivat oletus asetuksillaan (PolicyKit, upower jne). Kyllä sen systemd on voinut Arch Linuxiinkin asentaa AUR:ista jo vuodesta 2010.

Debian, eri BSD versiot vahvasti edustettuna palvelimissa. Ja ovat hyvin edustettuna palvelimien uptime kisassa. On sellaisia BSD koneita joissa uptime on vuosia. Linux hieman häviää kun laskurista loppuu päivät.

systemd on suunniteltu pitämään järjestelmä käyttökuntoisena periaatteessa loputtomiin. Siinä esimerkiksi palveluiden sammuttaminen ei jätä zombie prosesseja pyörimään ja kaikkia ohjelmien riippuvuuksia voidaan valvoa helposti.

RHEL 7 (eli CentOS, Scietific Linux, Oracle Linux...) siirtyy käyttämään systemd:tä, joka tekee siitä periaateessa de facto standardin. Saman tekee luultavasti myös SLES 12, koska openSUSE siirtyi siihen jo aikoja sitten ja RHEL on suunnannäyttäjä. Debian on hidas tekemään muutoksia, mutta ainakin systemd:tä tuetaan ja uskon siitä tulevan oletus init järjestelmä Linux ytimelle. Tällä hetkellä merkittävin syy miksi niin ei tehdä on se, että se ei tue FreeBSD ydintä joka on käytännössä lelu projekti. Ubuntu tukee jo nyt systemd:tä, koska se on osa heidän IVI alustaa. Samalla Upstart projektia ei ole kehitetty pitkään aikaan kunnolla (ei ollut mitään kehtitystä puoleen vuoteen ja nytkin vain pieniä korjauksia) eli oletettavasti sekin siirtyy käyttämään systemd:tä viimeistään 14.04 jälkeen.

systemd riippuvuudet hieman monimutkaiset ja monet sen vaatimat paketit eivät ole vielä saaneet stable asemaa.  Ja vakaus on tärkeämpi kuin parin sekunnin säästö käynnistysajassa.

Ei pidä paikkaansa. Kaikki sen riippuvuudet ovat vaikaita ja nopeat käynnistysajat on vain seuraus sen arkkitehtuurista. Se ei ole mitenkään sen pääominaisuus.

6

Muut käyttöjärjestelmät ja Linux-jakelut / Vs: Arch Linux

« : 15.08.12 - klo:16.16 »

Arch Linux on nyt parempi kuin koskaan. Olisi ollut valitettavaa, jos vanhasta init järjestelmästä olis pidetty kiinni paremman systemd integraation kustannuksella. Sama pätee myös /usr-siirtoon. On kiva käyttää jakelua, joka pysyy kehityksen mukana, eikä pidättäydy vanhassa vain sen takia, että niin on aina ennenkin tehty. Esimerkiksi Debianin syyt jättää systemd välistä on aivan naurettavia (mm. tuen puute BSD ja HURD kerneleille, jota käyttää luultavasti alle tuhannes Debian käyttäjistä).

Yksi syy nopeaan systemd siirtymiseen oli se, etteivät kehittäjät jaksanee enää kuunella näitä anti-systemd, anti-Lennart trolleja. Tekisi Archille vain hyvää, että nämä vaihtaisivat jakelua.

7

Yleistä keskustelua / Vs: Kysymys GNOMEsta

« : 12.08.12 - klo:15.44 »

Mitään suurempia muutoksia on mahdotonta tehdä ettei löytyisi äänekkäitä vastustajia.

Ero Gnomen tapauksessa on se, että ominaisuuksia poistetaan ilman hyvin perusteltuja syitä. Käytönnössä ainoa tapa saada niitä ikinä takaisin on forkkaus ja niin on nyt käymässä usean ohjelman suhteen. Tämä jatkuva yhteisön fragmentoituminen ei vaan voi jatkua loputtomiin. Miten tämä sitten vaikuttaa Gnome projektiin pitkällä tähtäimellä jää nähtäväksi.

Esimerkiksi KDE projekti menetti todella suuren osan käyttäjistään 4.0 aikoina. Ne ovat kuitenkin vuosien saatossa lisänneet käytännössä kaikki menetetyt ominaisuudet takaisin ja käyttäjä kunta on lähtenyt kasvuun. Jos oletukset eivät mielytä niin sen saa ainakin muokattua mieleisekseen. Gnome on tässä tapauksessa erilainen. Jos projektin visio ei maistu niin joudut etsimään uutta. Siksi myös potentiaaliset tappiot ovat paljon suurempia.

8

Yleistä keskustelua / Vs: Kysymys GNOMEsta

« : 12.08.12 - klo:12.58 »

Ubuntu kehittäjät toimivat mielestäni myös passiivisesti Nautiluksen suhteen.

Ongelma oli kai tässä tapauksessa lähinnä se, että ominaisuuksien pudottamisesta ei mainittu oikeasta missään mitään ennenkuin se tehtiin. Gnome ei ole ennalta-arvattava ja sen takia Ubuntu on jopa harkinnut yhden julkaisun väliä upstreamiin. Gnome projekti on hylännyt mm. Canonical dbus-menun ja indikaattorit, joka on osa syy miksi Unity ei toimi muilla jakeluilla. Se myös heijastaa sitä kuinka vaikea upstream Gnomen kanssa on työskennellä.

On mielenkiintoista nähdä miten yhteisö reagoi tuleviin Gnome projektin uudistuksiin. Käytännössä kaikkien ohjelmien käyttöliittymät menee uusiksi, eikä se varmasti miellytä kaikkia. Samalla Elementary/Yorba tuo jatkuvasti uusia ohjelmia, jotka perustuvat Gnome kirjastoihin, mutta poikeavat muuten radikaalisti sen ohjelmista ja Cinnamon/SolusOS tiimit luultavasti jatkavat ohjelmien patchaamista/forkkailua. Myös Ubuntu on forkannut ainakin Gnome Control Centerin, joka tuskin jää sen viimeiseksi. Sitten rinnalla vielä pyörii vielä MATE, joka saatetaan portata GTK+ 3, joka tekisi sen ohjelmista myös kilpailu kykyisiä näiden kanssa.

Tämä on tuhoisaa Ubuntun kannalta, koska sen on käytännössä mahdoton tuoda oikeasti yhtenäistä, helppo käyttöistä ja kilpaily kykyistä työpöytää markkinoille koodaamatta ohjelmiaan itse.

9

Yleistä keskustelua / Vs: Kysymys GNOMEsta

« : 12.08.12 - klo:00.17 »

Eikös  ainakin Unity ja Cinnamon perustu Gnomeen?

Ne pohjautuvat Gnome kirjastoihin ja sen ohjelmiin, mutta en silti lähtisi kutsumaan niitä "Gnomeksi". Esimerkiksi Ubuntu jo nyt korvaa useita Gnome projektin ohjelmia omillaan. Unity korvaa ikkunamanagerin, työpöydän, käynnistimen, valikot ja vierityspalkit. Ero tulee selvästi vain kasvamaan tulevaisuudessa, kun Gnomen ottama suuntaus ei Canonicalia innosta.

10

Yleistä keskustelua / Vs: Kysymys GNOMEsta

« : 11.08.12 - klo:14.58 »

Gnome on tehnyt paljon radikaaleja muutoksia viimeaikoina, joista viimeisin on ollut pudottaa monia monille tärkeitä ominaisuuksia Nautiluksesta pois. Tämän jälkeen Cinnamon tiimi forkkasi Nautiluksen Nemoksi, SolusOS on alkanu patchailemaan Nautilusta mieleisekseen ja Ubuntu on harkinnut sen vaihtamista johonkin muuhun tai vanhassa versiossa pysymistä.

Ei tuskin tule kenellekkään yllätyksenä, että Gnomen suosio on laskenut viimeisen vuoden aikana merkittävästi. Väkeä on valunut LXDE, XFCE, Unityn, Cinnamonin, KDE:n, Enlightementin ja Elementaryn pariin. Samalla Gnome on menettänyt kehittäjiä, vaikka sillä saralla tilanne ei kai ole hirveästi muuttunut.

11

Muut käyttöjärjestelmät ja Linux-jakelut / Vs: Linux Mint

« : 26.07.12 - klo:19.22 »

Kubuntunkin kehitys on käsittääkseni loppunut ainakin Canonnicalin puolesta loppunut  http://arstechnica.com/business/2012/02/canonical-ending-support-for-kubuntu-reassigning-lead-developer-1/ eikä  se koskaan ole mielestäni ollutkaan "oikea" KDE distro, vaan enemminkin ollut haitaksi KDE:n maineelle.

Kubuntulla saa nykyään enemmän taloudellista tukea kuin koskaan, vaikka Canonical ei sitä enää tue. Blue Systems palkkasi tuon entisen Canonicalin työtekijän jatkamaan työtään Kubuntu parissa. Sama yritys on palkannu myös muutamia muita kehittäjiä kehittämään Kubuntua, Netrunneria ja Linux Mint KDE:ä. Sen palkkalistoista taitaa löytyä nykyään jo yli kymmenen KDE kehittäjää.

12

Muut käyttöjärjestelmät ja Linux-jakelut / Vs: Fedora Unityllä

« : 20.07.12 - klo:15.33 »

Ei Unity kyllä Fedoran virallisiin repoihin tule pääsemään pitkään aikaan. Ongelmana on se, että Unity vaatii lukuisten kirjastojen patchaamista, joka ei vaan käy päinsä. Sama kehittäjä on portannut Unityn myös Arch Linuxiin, jossa se on saatavilla AUR:sta.

13

Ohjelmointi, palvelimet ja muu edistyneempi käyttö / Vs: Qt4 ja ohjelman julkaiseminen

« : 26.06.12 - klo:01.54 »

Qt on LGPL licensoitu eli kyllä. Qt:hen tekemäsi muutokset joudut kuitenkin julkaisemaan avoimena koodina. Oman ohjelmasi voit pitää suljettuna tai myydä sitä eteenpäin.

14

Pelit / Vs: Steam ja Source tulossa (oikeasti) Linuxille

« : 21.06.12 - klo:16.21 »

toiveessa on hyvä elää. varsinkin kun vetoomuksessa natiivissa linux tuen saamisessa WOW on yli miljoona allekirjoittajaa. tietääkseni.

Tuo kuulostaa jokseenkin mahdottomalta. Ei käytännössä mikään adressi kerää niin paljoa nimiä vaikka se koskisi kuinka monia ja tässä tapauksessa kyse on kuitenkin melko marginaalisesta ryhmästä. Ensinnäkin WoW pelaajia on vain se 11 miljoonaa. Näistä luultavasti alle 5% käyttää Linuxia ja niistäkin jotka sitä käyttävät vain murto-osa on tietoisia kyseisestä adressista (Jos sitä edes on olemassa enää, löysin vain yhden jossa oli alle 25k nimeä).

Voisin kuvitella, että käytännössä kaikki pelipalvelimet käyttävät Linuxia ja siksi osaajia tarvitaan vaikka pelejä ei alustalle oltaisikaan tuomassa. En kuitenkaan pidä yhtään mahdottomana, etteikö näin voisi käydä. Käsittääkseni Blizzard jo nyt pitää huolen siitä, että WoW toimii Winellä.

15

Yleistä keskustelua / Vs: Red Hatin UEFI-päätös voi koitua "kohtalokkaaksi" Linux desktopille?

« : 21.06.12 - klo:00.53 »

Jos tarkoitat Matthew Garrettia, niin hän tietää asia varsin hyvin.

"A system carrying only the Ubuntu signing key will conform to these requirements and may be certified by Canonical, but will not boot any OS other than Ubuntu unless the user disables secure boot or imports their own key database. That is, a certified Ubuntu system may be more locked down than a certified Windows 8 system."

Tuota vain mietin, mutta tosiaan ymmärsin hieman väärin. Ubuntu läppäri, jossa Secure Boot on päällä (jonka saa siis aina pois (vaatimus) ja siten minkä tahansa käyttöjärjestelmän asennettua) on enemmän lukittu kuin vastaava Windows asetus, koska Windows tietokoneiden Secure Boot käynnistää kaikki sertifikoidut ytimet (Fedora, Windows, Ubuntu...) ja tarjoaa palvelun uusien sertifikaattien lisäämiseen kun Ubuntu käynnistää vain Ubuntun. Yksi asia jäi itselleni hieman epäselväksi: kuuluuko asetus Secure Bootin pois ottamiseksi Windows käyttöjärjestelmän rauta sertifikoinnin vaatimuksiin? Sellaisen kuvan sain kirjoituksesta, mutta se on ristiriidassa aikaisempien tietojeni kanssa. Jos näin on niin suurin ongelma Secure Bootin kanssa on vältetty, minkä tahansa käyttöjärjestelmän voi asentaa mihin tahansa x86 Windows tietokoneeseen myös jatkossa.

16

Yleistä keskustelua / Vs: Red Hatin UEFI-päätös voi koitua "kohtalokkaaksi" Linux desktopille?

« : 20.06.12 - klo:20.13 »

En kyllä nauti tilanteesta jossa "Ubuntu yleistyy Kiinassa ja Intiassa" jos tuloksena on se, että sinä et voi asentaa sen paremmin Windows- kuin Ubuntu-koneeseen mitään muuta käyttöjärjestelmää.Tuollaisesta Linuxin yleistymisestä en oikein jaksa iloita.

Ei Secure Boot ole seurausta siitä, että Dell myy Ubuntua esiasennettuna tuhansissa liikkeissä. Kaikkii näihin koneisiin voi asentaa myös minkä tahansa muun käyttöjärjestelmän, kunhan ottaa Secure Bootin pois päältä jos se edes on käytössä. En tiedä onko kyseisen artikkelin kirjoittaja ymmärtänyt jotain väärin, koska Windows 8 ei vaadi Secure Boottia toimiakseen.

17

Yleistä keskustelua / Vs: Red Hatin UEFI-päätös voi koitua "kohtalokkaaksi" Linux desktopille?

« : 20.06.12 - klo:14.28 »

End of PC as we know. Tulevaisuudessa on vain lukittuja koneita ja ekosysteemeitä jotka eivät keskustele toisten kanssa.

Vai niin... kyllä se suunta nyt on ollut jo aika pitkään aivan toiseen suuntaan. Avoimet rajapinnat ovat yleistymässä vähän joka sektorilla. Eikä tämä vaikuta oikeastaan mitenkää ainakaan laajempii hankintoihin (valtio, koulut, yritykset...). Sekä Ubuntu että Fedora toimivat ilman muutoksia Secure Boot koneissa ja käsittääkseni tarkoitus on tarjoita palvelua, jolla omia binaareja voi allekirjoittaa.

Vaikka muutos on ikävä, ei se ole katastrofaalinen. Toivoa voi hakea myös siitä, että Ubuntua myydän nyt Intiassa ja Kiinassa tuhansissa liikkeissä esiasennettuna.

18

Pelit / Vs: Steam ja Source tulossa (oikeasti) Linuxille

« : 19.06.12 - klo:23.19 »

Aika moni peli nykyää saa toimimaan linukas. mikä teijä.mielest on paras distro jos nyt o vältttämät pakko saada hakata jotain peliä?

Ei jakelulla ole käytännössä mitään väliä. Parhaan suorituskyvyn saat usein uusista julkaisuista, joissa on uusimmat ajurit ja Wine. Compiz heikentää hieman grafiista suorituskykyä niin siinä mielessä Unity on huono, toisaalta vaikutus on marginaalinen. Helpointen pääset *ubuntu perheen jakeluilla. KDE on erittäin hyvä työpöytäympäristö pelaamiseen, koska se osaa ottaa pois compositingin kokoruudun ikkunoilta (asetus löytyy tehosteiden asetuksista).

19

Yleistä keskustelua / Vs: Mitä Windows-järjestelmä valmiiksi asennetuissa koneissa maksaa?

« : 17.06.12 - klo:00.34 »

Isoille toimijoille(myynnit miljoonia kappaleita) hinta on joitaki kymppejä per kone. Siksi hinta on niissä sama tuli windows tai ei.

Näinhän se on. Yksi hintaa alentava tekijä on myös esiasennettu crapware, josta valmistajat saavat rahaa.

20

Muut käyttöjärjestelmät ja Linux-jakelut / Vs: EDE Desktop

« : 16.06.12 - klo:14.31 »

Itse pääsin joskus LXDE:llä  ~30MB muistinkulutukseen. Voisin kuvitella, että EDE:llä mentäisiin vielä alemmas, mutta en ole vielä saanut testattua. KDE:llä (KWin&Plasma) pyörittiin n. 65MB tietämissä. Tietenkin kernel, X.org ja muut välttämättömät komponentit syövät tuosta vielä sen 15-20MB, joten ihan hirveästi alastapäi ei niihin kajoamatta pääse.