Announcement

Collapse
No announcement yet.

Fedora 18 "Spherical Cow" Beta Finally Released

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • mark45
    replied
    Originally posted by AdamW View Post
    My take on that is in this thread.
    Technically it's a sound take on UEFI.
    But there's quite a childish argument about M$, we all know how Microsoft has been (and is) trying to screw Linux (and not just Linux, and it's not just about Microsoft), no need to repeat, not even their World Tour attempt to claim ownership of Linux with "undisclosed patents" - but it's unfair to Microsoft cause they've done so much more to screw Linux that one needs an entire wiki to count their "merits".

    And you're talking on that forum as if that didn't happen or if somehow God intervened and Microsoft suddenly only cares about its product quality. You also seem to believe that Microsoft caring about a better BIOS and creating problems for competition somehow exclude each other. You're also mentioning "the conspiracy theories are a load of bullcrap" - a lot of stuff in the world is done in conspiracy - it's one of the most natural and real things actually happening: from price-fixing done in conspiracy among corporations, down to mafia, CIA, coups, drug-cartels etc etc - they all act in conspiracy, so do a lot of corporations when bribing (judges, senators, especially in the USA since it's legalized) or working with/for the government and all the shitocracy around it.

    Leave a comment:


  • AdamW
    replied
    Originally posted by mark45 View Post
    It makes sense, but in reality it's not just about fixing the OS loading issue, it opened up a big opportunity for Microsoft to screw us (probably like never before), just read this blog. As I said, the catch is that some euphemism would be a /must/, in this case it's "security" which is used as a tool to wage and cover Microsoft's warfare strategy.
    My take on that is in this thread.

    Leave a comment:


  • mark45
    replied
    It makes sense, but in reality it's not just about fixing the OS loading issue, it opened up a big opportunity for Microsoft to screw us (probably like never before), just read this blog. As I said, the catch is that some euphemism would be a /must/, in this case it's "security" which is used as a tool to wage and cover Microsoft's warfare strategy.
    Last edited by mark45; 11-28-2012, 12:08 AM.

    Leave a comment:


  • linuxl4
    replied
    how about those:

    70% SysV to Systemd Porting from sysVinit init scripts to systemd unit files.
    80% New Installer UI Enhancing the anaconda installer with a new user interface, improving both the end-user experience as well as ease of implementation of new features, particularly new storage technologies, for developers.
    95% rngd default-on rngd (part of the rng-tools package) should be enabled by default.
    99% Secure Boot "Secure Boot" describes a UEFI feature by which malware is prevented from inserting itself into the boot process before the operating system loads. The UEFI feature is required to be enabled on all machines bearing the Windows 8 Client logo, which will be the overwhelming majority of all desktop and notebook systems.

    Leave a comment:


  • AdamW
    replied
    Originally posted by mark45 View Post
    Yes, from this perspective UEFI sounds attractive.
    But imo the problem is that the firmware is closed source (with restrictions like it's forbidden to reverse engineer it or so) and usually of bad quality (has bugs and tested like "if it boots windows it's fine").
    All commercial BIOS implementations are also closed source, nothing is different there. UEFI is a standard, not a codebase: you can write a closed source or open source implementation as you wish. (There are, I believe, already two open source implementation of UEFI available for virtualization use - one for qemu/kvm, one for VirtualBox). BIOS is also a standard, though it's a de facto rather than de jure standard. Anyone can write an implementation of either, and release it under any license they choose. If anything, UEFI is better than BIOS here, because at least UEFI is an *actual defined standard* and we can write Linux to comply with it, and if a UEFI implementation is out of spec, we can complain about that. Since there's no formal BIOS standard, a manufacturer could theoretically build a machine with a gimped-up 'BIOS' that can only boot Windows or anything else you like, and there is no actual written document you could accuse them of violating. (edit: if you mean the movement of some bootloader logic from the potentially-open source OS layer to the probably-proprietary system firmware layer constitutes a loss of freedom, now I think about it, you're right, but frankly, I'd trade that off against the hideousness of the BIOS design any day...a system with an open source UEFI firmware would be the best thing though, of course).

    Originally posted by mark45 View Post
    Not to mention that hardware/firmware vendors might do something against desktop Linux on behalf of Microsoft under the aegis of some euphemism (like security or whatever), and if those firmware stop working in a standard way with Linux - you're helpless. In the current environment you at least program grub2 yourself and no one controls you.
    Again, this is not at all unique to UEFI. They could do that anyway. If someone wants to gimp up a firmware such that it doesn't work with Linux, they don't need to do that via the bootloader mechanism. You could do that with a BIOS implementation if you really wanted to.

    Leave a comment:


  • mark45
    replied
    Yes, from this perspective UEFI sounds attractive.
    But imo the problem is that the firmware is closed source (with restrictions like it's forbidden to reverse engineer it or so) and usually of bad quality (has bugs and tested like "if it boots windows it's fine").
    Not to mention that hardware/firmware vendors might do something against desktop Linux on behalf of Microsoft under the aegis of some euphemism (like security or whatever), and if those firmware stop working in a standard way with Linux - you're helpless. In the current environment you at least program grub2 yourself and no one controls you.

    Leave a comment:


  • AdamW
    replied
    Originally posted by mark45 View Post
    Thanks, since in reality neither Apple nor M$ want to be compatible with desktop Linux (recall the recent news with UEFI/keys/whatever being dependent on silverlight is yet another reminder of M$'s dirty games), the most reasonable way to me is to keep updating grub2 with new code capable of listing new versions of window$ and mac and those unix-like systems that use grub2 - if you're not either of these 3 you're not worth the effort since those other OSes would be like 0.01% of the desktop market - this imo would be straightforward and would save quite a lot of code and maintenance woes.
    Though this thought doesn't apply to the new uefi/secure boot standard.
    In practice that doesn't narrow down the problem space much.

    For gedanken purposes, the problem space is this, on a BIOS PC.

    * There can be almost any amount of disks attached to the system.
    * The user can choose to 'boot from' - that is, initiate the boot sequence using whatever is in the MBR of - any one of those disks on any given boot.
    * What is on any of those disks and what is in the MBR of any of those disks can change without any warning to you if you are a single OS on the system.
    * Any of the MBR-based bootloaders can, and may, chainload another bootloader located in the header of any partition on any disk in the system.
    * Any bootloader on the system (MBR or partition) can attempt to directly boot any other OS installed on the system (including any kernel pair that has ever existed, potentially, for any Linux install present).
    * There is absolutely no de jure or de facto standard or even best practice for configuring multiboot. Different sysadmins and OSes can and will have things set up via shared bootloaders, or chainloading, or any other way in any given system.

    So...yeah. That's your problem space. Migraine commencing in...3...2...1...

    The UEFI design is at least theoretically miles, miles better than this. The design is that a list of 'things that can be booted' is maintained by the system firmware, and *only* by the system firmware. If you are an OS, at install time, you register yourself in the firmware's boot menu, with an entry which tells the firmware what your OS is called and what second-stage bootloader it should call when the user chooses to boot you. You install your second-stage bootloader (in a fairly standardized way) and configure it to handle _only_ booting yourself. You do not attempt to deal in any way at all with booting any other operating system, you leave that up to the firmware and the OS in question. It's a far better design. I dream of a future where everyone's finally adopted it and I can forget all the hideous knowledge I've built up about BIOS-based booting...

    Leave a comment:


  • mark45
    replied
    Thanks, since in reality neither Apple nor M$ want to be compatible with desktop Linux (recall the recent news with UEFI/keys/whatever being dependent on silverlight is yet another reminder of M$'s dirty games), the most reasonable way to me is to keep updating grub2 with new code capable of listing new versions of window$ and mac and those unix-like systems that use grub2 - if you're not either of these 3 you're not worth the effort since those other OSes would be like 0.01% of the desktop market - this imo would be straightforward and would save quite a lot of code and maintenance woes.
    Though this thought doesn't apply to the new uefi/secure boot standard.
    Last edited by mark45; 11-27-2012, 10:31 PM.

    Leave a comment:


  • AdamW
    replied
    Originally posted by mark45 View Post
    You're right on this one, I actually downloaded & clean installed F16 right now and despite the boot screen looking like legacy (black-n-white and clunky) grub, it says "grub 1.9" which is technically grub2 or so, so I was wrong on that one, though you're also right that I'm misremembering: the fact that it looks old and didn't detect Ubuntu contributed to this misbelief I guess. But here's the more important part to me as a (grub) user - it (F16) doesn't (and didn't) detect Ubuntu, which to a user it is as bad as using grub legacy - both sucked - F15 with grub legacy and F16 with grub2 (1.99) - while Ubuntu's grub2 worked fine long before (e.g. it detected Fedora).

    So my question would be - does Fedora 18 detect Ubuntu? And are there plans to use Ubuntu's simpler commands like grub-install & update-grub?
    The detection of existing OSes is a pure grub feature, both we and Ubuntu are simply using that code from upstream grub - when you call grub(2)-mkconfig it does that automatically. If it didn't work for you in F16 then it simply means the version of grub2 in F16 had a bug in that code of some kind. That may have been fixed by the version in F18, it is a much newer version. I've only tried installing F18 alongside Ubuntu once, and the grub detection worked, but that's hardly enough testing for me to guarantee that it always works in all configurations ever, so I'm not going to do that, but hey, the code is there and it fires.

    Now having said that, even if a Fedora install does detect an Ubuntu install and add it to the bootloader configuration written by the Fedora install process, booting Ubuntu from that config is not necessarily going to be trouble-free, especially as Fedora uses grubby to update the config afterwards, not mkconfig, so it won't update the Ubuntu entry each time the config is updated.

    I have a giant screed on dual booting I could go into here but won't, but suffice it to say that the traditional x86 way(s) of handling dual/multiple boot are all terrible, terrible hacks and every one of them is badly flawed. Multiboot is one of the few things UEFI at least potentially improves, as it keeps the OS selection stuff in the firmware, which is the only logical place for it. Having five operating systems fighting over how to boot the system, each with their own bootloader and bootloader config - or, equally, having five operating systems fighting to maintain *one* bootloader config - are both recipes for pain, whatever the precise details of your setup. The only way of dual-booting in a non-UEFI setup that I'd be happy with would be not more than one OS per disk, with each OS controlling the MBR on its own disk and never touching any of the others, tbh.

    I haven't tested the grub2 method extensively but I know how it works, and at least in theory, if you have multiple grub2-based OSes dual-booting and they all use grub(2)-mkconfig to update whichever bootloader config file they decide to touch, it _ought_ to mostly hang together. But it's still a pretty creaky mess. Sigh, PCs.

    edit: there aren't any clear plans to use grub2-mkconfig to maintain the Fedora bootloader config file in the near future, no. It will probably keep popping up as a discussion topic and happen eventually, though. That's just my guess.

    Leave a comment:


  • mark45
    replied
    Originally posted by AdamW View Post
    Your motherboard does not support UEFI. If you did an out-of-the-box F16 install on it you would get grub2. You must be misremembering in some way. I can't find any relevant posts on the forums, but I didn't look crazy hard.
    You're right on this one, I actually downloaded & clean installed F16 right now and despite the boot screen looking like legacy (black-n-white and clunky) grub, it says "grub 1.9" which is technically grub2 or so, so I was wrong on that one, though you're also right that I'm misremembering: the fact that it looks old and didn't detect Ubuntu contributed to this misbelief I guess. But here's the more important part to me as a (grub) user - it (F16) doesn't (and didn't) detect Ubuntu, which to a user it is as bad as using grub legacy - both sucked - F15 with grub legacy and F16 with grub2 (1.99) - while Ubuntu's grub2 worked fine long before (e.g. it detected Fedora).

    So my question would be - does Fedora 18 detect Ubuntu? And are there plans to use Ubuntu's simpler commands like grub-install & update-grub?
    Last edited by mark45; 11-27-2012, 10:00 PM.

    Leave a comment:

Working...
X