Announcement

Collapse
No announcement yet.

KDE's Nepomuk Doesn't Seem To Have A Future

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

  • #71
    Originally posted by asdfblah View Post
    Well, in web browsers is very easy and convenient to avoid just that: Use a "incognito" session or delete everything by pressing ctrl+shift+del.

    In kde, as you say, you'd have to delete that folder to prevent anyone looking at your personal data...

    For my example, I had cyber cafes in mind (which these days still exist in poor countries) and poor people's shared computers. What if devs changed things so you could use a "private session" in which you could (momentarily) disable the collection of data, by one app, or by the whole desktop environment? What if they integrated encryption, so you could access your data only by using passphrases (which would be annoying, but it could be made optional too)?
    If you share the account, you share the data, so dont do it.

    If you have persistent accounts, everyone gets his/her own account, nothing to workaround on the desktop level. If you want, use encryption for the home folder, but this should be done on the system level, e.g. use LUKS or encFS, and use pam_mount to mount your home partition on login.

    If you have nonpersistent logins, e.g. for one time visitor in an internet cafe or a guest account on your computer, wipe the whole home partition on logout (use e.g pam_exec) and create a fresh home on login (pam_mkhomedir).

    Originally posted by asdfblah View Post
    AFAI understand, if you want security in your applications, you have to code things with security in mind. There are lots of mechanisms in compilers and the kernels themselves to prevent the exploitation of bugs in the code, but if the applications are not written with security in mind, these mechanisms are useless.
    If you want privacy, put the data somewhere only readable by yourself. Thats what directory permissions are for. Let the kernel enforce this, and do not increase complexity where it is not necessary.

    Comment


    • #72
      Originally posted by omer666 View Post
      Didn't try Evolution ?
      Indeed I did. I went on a 3-month long journey trying to figure out what the next 3 years of my IT choices and budget would look like. When I choose a vendor, I tend to go all-in for a set period of time. A good example is when I purchased my house in 2007, I budgeted our entertainment center. After looking through all the options, I ended up going with Sony as a vendor (TV, receiver, PS3, speakers, zone-2 amplifier, etc). All my warranties line up. I have one account with the vendor. I have one local authorized service center. I have one controller (PS3 wireless BD remote). I have one Zip lock freezer bag containing all the manuals and registrations with a sticker on the front that says "Sony Stuff". Etc.

      I probably could have gotten a bit of a better screen from Panasonic. I could have saved money by going with Onyko or gotten a better receiver for the same money from Yamaha. I probably could have gotten better speakers from Polk, or via DIY/Dayton and partsexpress.com. I probably could have tied it all together with a Logitech Harmony remote. The effort to set it all up, maintain it, and convey the workings to my wife and 4-year-old would have overshadowed any benefit the piecemeal components could have possibly delivered.

      Our home IT changeover a few years ago was the same. 2 iPhones 4/5, an Apple TV, Airport Extreme, an iPad 3 with cradel and HDMI adaptor, 1 iMac, 1 Macbook Pro. Our 2 PCs were converted to Hackintoshes. We moved all of our online groupware to iCloud. It's a leap, not a jump, and it's had it's share of problems (no shared iPhoto albums for example). On the bright side, the groupware has been a godsend. Prior to this, we had attempted to use Ubuntu in conjunction with Google's cloud services. We simply did not use it, or rather, we avoided using it, because it was burdensome and clumsy.

      I think the only disparate component I own now is a Wii-U, which is a tremendous amount of fun to play with my kid, but has been an IT/Consumer nightmare. Apple should just buy Nintendo. I'll spare you from my Nintendo gripes though.

      (Disclaimer, I worked for MS from 1999 to 2004)

      Comment


      • #73
        Originally posted by Awesomeness View Post
        KMail stores its mails in a regular maildir hierarchy. Corrupting all mails is pretty much impossible.
        Considering we're talking about a guy who "fixed" data corruption by migrating to HFS+, he almost certainly just lost some index files and was incapabke recreating them?
        Not since 4.5. There is a reason KMail from KDE 4.4 is still used many places (I use it with latest KDE). It is that last one that doesn't load it to a MySQL database, corrupts half of it and then allows you to browse emails where loading one email now takes 2 minutes (though to be fair, over time it takes even longer until it stops working).

        I don't say that as a troll, I say that as a KDE developer and fan who originally switched to Linux as my primary desktop because of KMail.

        Comment


        • #74
          Originally posted by russofris View Post
          Kmail/PIM/KOffice has cost me about $50,000 due to datastore corruption which resulted the loss of my contacts and several months worth of correspondence, even after rolling tape to recover what I could.
          Several months? Your backup scheme must be lousy.

          Comment


          • #75
            Originally posted by carewolf View Post
            Not since 4.5. There is a reason KMail from KDE 4.4 is still used many places (I use it with latest KDE). It is that last one that doesn't load it to a MySQL database, corrupts half of it and then allows you to browse emails where loading one email now takes 2 minutes (though to be fair, over time it takes even longer until it stops working).

            I don't say that as a troll, I say that as a KDE developer and fan who originally switched to Linux as my primary desktop because of KMail.
            That is simply a myth. Kmail 4.5+ still uses maildir (or mbox) for mail storage, MySQL is merely used for things like caching regularly-used data.

            Comment


            • #76
              Originally posted by TheBlackCat View Post
              That is simply a myth. Kmail 4.5+ still uses maildir (or mbox) for mail storage, MySQL is merely used for things like caching regularly-used data.
              So why does converting all my emails take over 24hours, and why do I end up with a mysql database of 50Gbyte? KMail2 can import from maildir, but doesn't use it for primary storage, it uses akonadi, and akonadi uses QtSQL and defaults to using the MySQL backend but can also be forced to use a number of other database backends.

              I managed to get things almost working last time I tried upgrading KMail2, but then I typed one password wrong and hit this thing: https://bugs.kde.org/show_bug.cgi?id=328061

              I will try again on the next release, it will mark the 5th time I try upgrading. Just glad I always refresh my backup each time I try now. First time I lost 3 months of email when I had to restore from backup.
              Last edited by carewolf; 17 February 2014, 04:01 PM.

              Comment


              • #77
                re: privacy
                I'm responding to a post back on page2, to mention that I had "left the KDE flock" due to nepomuk/akonadi,
                and that I welcome the project's apparent direction (toward more loosely coupled components).
                Originally posted by Ericg View Post
                Depends on who this mystery other person is...
                ... has root and chooses to snoop.
                I believe we should separately consider "security" and "privacy". Personally, I feel nearly zero worry regarding any person(s) having physical access to my desktop pc.
                I don't encrypt disks, I have the pc setup to auto-login (non-root acct) to desktop... yet I worry quite a bit about privacy in terms of the potential for my private data (metadata, usage habits, etc) to be leaked / harvested via network-enabled apps. My worries are borne from having witnessed, firsthand, numerous instances of "inbuilt, by design" data leakage.

                Early on, I read: "you can easily disable"
                but, aghast, discovered that my previously-stated preferences were silently ignored, overruled, reset to default (?) by package upgrade post-install directives.

                I've repeatedly read: "if yer uncomfortable, you can just do the builds yer own tinfoilhat self".
                Thankyouverymuch for that truism. FWIW, I wasted many hours attempting to to so, and failed (failed to overcome component dependency issues).

                Amarok.
                Upon noting the first-run behavior (due to pre-configured settings therein) of Amarok, during a live trial of (IIRC) Kubuntu 13.2, I wondered "who's responsible for this ridiculousness?" The app shipped with various plugins installed, and pre-enabled (to "enhance my user experience" dontchaknow) such that, upon first double-click of a suitable minetype file... app starts up and performs callouts, spewing telemetry to ELEVEN remote parties. Thankfully, in this particular distro/release, drives were not automounted nor was Amarok pre-configured to scour my partitions, building a manifest of my collected media files and oh-so-helpfully calling out to lastFM etc. under a premise of "retrieving album art" or whatever. I don't know (nor do I have the time to investigate) whether the KDE project ships Amarok with those (use is never asked to opt in) defaults, or whether the end result reflects the decision of the distro package maintainer. In either case, by "partnering", apparently attempting to fund the project via partnerships which, by design, harvest my private (meta)data... the current interconnected-everything represents an intolerable environment for me.

                If Krita, Basket, etc were independent (vs akonadi-connected, akonadi-dependent) apps, I would enthusiastically financially support their ongoing development.
                (Admittedly, given its expected usage, Basket is an especially unlikely candidate for independence.)
                In the meantime, I disdainfully avoid the (feels to me like) Borg-like KDE status quo.
                (BTW, apps within the Gnome project currently "abuse user privacy" similarly, by harvesting the gvfs-metadata store and silently sending telemetry.)

                worded differently, to close on a positive note:
                I look forward to using, and financially supporting development of Krita, Basket, etc, when loosely coupled versions of them become available.

                Comment


                • #78
                  Originally posted by carewolf View Post
                  So why does converting all my emails take over 24hours, and why do I end up with a mysql database of 50Gbyte? KMail2 can import from maildir, but doesn't use it for primary storage, it uses akonadi, and akonadi uses QtSQL and defaults to using the MySQL backend but can also be forced to use a number of other database backends.
                  Please don't call yourself a KDE developer if you even don't get this right, after all the time it exists...
                  The SQL part is ONLY FOR CACHING! The mails still exist as plain text. AFAIR it is a simple maildir. I don't remember where those mails are stored, but you should find the location by walking through ~/.local and ~/.kde.

                  Comment


                  • #79
                    Originally posted by schmalzler View Post
                    Please don't call yourself a KDE developer if you even don't get this right, after all the time it exists...
                    The SQL part is ONLY FOR CACHING! The mails still exist as plain text. AFAIR it is a simple maildir. I don't remember where those mails are stored, but you should find the location by walking through ~/.local and ~/.kde.
                    Interesting cache that is bigger than the files. The emails and other akonadi data is stored in .local/share/akonadi btw. Technically if you do not use ANY subdirectories you can get the local emails in maildir format in .local/share/local-mail. But you do get the part where I have hundred of thousands of emails, right? Just kde-commits for the last month is more than any sane person would have in a single folder. I don't store them in a single directory, and unlike old Kmail, akonadi can not store tree subdirs in maildir format (the old Kmail way was a bit of a hack, but at least it worked).

                    Comment


                    • #80
                      Love KDE, and I'm even happy with Akonadi. I'm even like the concept of nepomuk, but I hate the nepomuk implementation with a passion.

                      Comment

                      Working...
                      X