Announcement

Collapse
No announcement yet.

ChromeOS Drops Support For EXT2/EXT3/EXT4 File-Systems

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

  • #51
    I hate google, but damn yes I fully agree with this. Linux needs proper disk labeling. I've never been able to install Linux on a machine properly because there's no reliable way to identify the hardware. Seriously, how am I supposed to know which drive/partition is which when the cryptic code changes every time on boot? I always physically remove disks so there is only one drive that can be ruined. It's a confusing (and undocumented) mess.

    I hope this decision by google this will bring this issue to attention.
    Last edited by Remdul; 13 October 2014, 07:59 AM.

    Comment


    • #52
      Originally posted by Passso View Post
      Fools are 90% of IT users, live with that and be happy for now because this % will increase year after year.
      While ChromeOS can survive losing 10% of fools, I think that losing the 10% smart users will hurt much more.

      And that is what happens: The average dumb user does not know or care about ext4. And the users who have ext4 on their external storage are the smarter ones which run beta/dev channel, report bugs, or could even turn into ChromiumOS contributors one day. Now they are being alienated by the decision to drop ext4 support.

      Comment


      • #53
        Originally posted by Blahblah View Post
        What a garbage reason to remove something as useful as file-system support. I imagine this decision is more poltical than it appears, though I can't imagine how it would benefit anybody at Google.
        It could also be a push for Cloud storage. Notice all the new devices with missing SD Cards in them? Cloud 9 baby.

        Comment


        • #54
          This article is a detector - if you are enraged, then you are "Free software" supporter. Otherwise, you are "open source" supporter.
          Difference? "Open source" gives you the freedom to do bullshit and get away.

          Comment


          • #55
            Originally posted by Remdul View Post
            I hate google, but damn yes I fully agree with this. Linux needs proper disk labeling. I've never been able to install Linux on a machine properly because there's no reliable way to identify the hardware. Seriously, how am I supposed to know which drive/partition is which when the cryptic code changes every time on boot? I always physically remove disks so there is only one drive that can be ruined. It's a confusing (and undocumented) mess.
            All of my Linux Ext3 and Ext4 partitions are labelled, both on my internal and USB disks.

            Comment


            • #56
              Originally posted by Remdul View Post
              I hate google, but damn yes I fully agree with this. Linux needs proper disk labeling. I've never been able to install Linux on a machine properly because there's no reliable way to identify the hardware. Seriously, how am I supposed to know which drive/partition is which when the cryptic code changes every time on boot? I always physically remove disks so there is only one drive that can be ruined. It's a confusing (and undocumented) mess.

              I hope this decision by google this will bring this issue to attention.
              what has labeling with reliable naming and identifying your devices and what exactly are your issues with labeling on ext devices?

              edit: beside of that, when installing windows or linux you either have an unformated device, so no labels anyway, or you can see them during installation (at least on most common linux distris). your whole post makes no sense in so many ways.

              p.s. and what cryptic code are you talking about that changes on boot?
              Last edited by a user; 13 October 2014, 02:12 PM.

              Comment


              • #57
                Originally posted by Remdul View Post
                I hate google, but damn yes I fully agree with this. Linux needs proper disk labeling. I've never been able to install Linux on a machine properly because there's no reliable way to identify the hardware. Seriously, how am I supposed to know which drive/partition is which when the cryptic code changes every time on boot? I always physically remove disks so there is only one drive that can be ruined. It's a confusing (and undocumented) mess.

                I hope this decision by google this will bring this issue to attention.
                Hahahaha!

                man blkid
                man tune2fs | grep 'UUID'

                You can mount by:
                - drive position on controler
                - label
                - partition UUID
                - hardware serial

                Comment


                • #58
                  EXT* support will be back

                  Due to the overwhelming response, Google retraced their steps.

                  Chromium Bug
                  Thanks for all of your feedback on this bug. We've heard you loud and clear.

                  We plan to re-enable ext2/3/4 support in Files.app immediately. It will come back, just like it was before, and we're working to get it into the next stable channel release.

                  Comment


                  • #59
                    Nice that they will fix this, but the damage has been done. Both in ChromeOS and in Android, Google has proven that they will use free software only as long as it immediately benefits their goals. They have no real loyalty to the upstream, and no particular loyalty to the ethics of free software.

                    I am sure that if, in the future, Linux becomes too much work for them in terms of collaboration with the community, they will simply "pull an Apple": rebase Android/ChromeOS on a BSD, and stop even trying to contribute upstream.

                    Via Android, Linux has come to dominate the mobile world, which is amazing. But we should not rest on our laurels. Android is seeing more and more core elements becoming proprietary every day. At some point, Google will replace the kernel, too.

                    I know it's popular here to hate on Canonical. Of course they made BIG mistakes in the past in communicating their decision process to the community (that remind me a bit of Google's weird decision here with ext filesystems). But the fact is, Canonical is truly commited to free software, and for every feature it removes, it provides support for alternatives (Xubuntu, Kubuntu, etc.). We should do everything we can to make sure Ubuntu Touch succeeds, so that when Google finally throws Linux away, we'll still be able to have free (libre) mobile devices. Don't like Ubuntu Touch? It's still Ubuntu, and I'm sure alternative mobile UIs will be available (I'm planning to make one myself!), building on the solid foundations of Linux and FLOSS.

                    (For the same reason, we should be promoting Firefox over Chrome. Mozilla's commitments are crystal clear. Google simply cannot be trusted.)

                    Comment


                    • #60
                      Originally posted by emblemparade View Post
                      Nice that they will fix this, but the damage has been done. Both in ChromeOS and in Android, Google has proven that they will use free software only as long as it immediately benefits their goals. They have no real loyalty to the upstream, and no particular loyalty to the ethics of free software.

                      I am sure that if, in the future, Linux becomes too much work for them in terms of collaboration with the community, they will simply "pull an Apple": rebase Android/ChromeOS on a BSD, and stop even trying to contribute upstream.

                      Via Android, Linux has come to dominate the mobile world, which is amazing. But we should not rest on our laurels. Android is seeing more and more core elements becoming proprietary every day. At some point, Google will replace the kernel, too.

                      I know it's popular here to hate on Canonical. Of course they made BIG mistakes in the past in communicating their decision process to the community (that remind me a bit of Google's weird decision here with ext filesystems). But the fact is, Canonical is truly commited to free software, and for every feature it removes, it provides support for alternatives (Xubuntu, Kubuntu, etc.). We should do everything we can to make sure Ubuntu Touch succeeds, so that when Google finally throws Linux away, we'll still be able to have free (libre) mobile devices. Don't like Ubuntu Touch? It's still Ubuntu, and I'm sure alternative mobile UIs will be available (I'm planning to make one myself!), building on the solid foundations of Linux and FLOSS.

                      (For the same reason, we should be promoting Firefox over Chrome. Mozilla's commitments are crystal clear. Google simply cannot be trusted.)
                      I respectfully disagree; the removal of this specific feature could have been a wrong choice by a couple of devs and a supervisor. In fact, the reversion just showed us that the same guys are willing to listen to what people has to say. Google is not an all-good-or-evil corporation. Loyalty is not to be judged by one wrong action of a couple of guys alone, but it should be measured in terms of all of the google devs' contributions to free and open source software, which can be seen in their public source code commits, as well as other right and wrong choices from Google's history with the FOSS community.

                      Google may always pull an Apple on all of us, but Chrome OS is already on the hands of the public through open source licenses.

                      If the day comes that Google replaces the Android kernel, we will keep working on the Linux kernel and Google will not be able to take their contributions back.

                      All open source contributors make mistakes every now and then. That does not make organizations all-bad or all-good. Let's just keep our voices up to be heard and shape the open source world together.

                      Comment

                      Working...
                      X