Slashdot Mirror
Endless OS Now Ships With Steam And Slack FlatPak Applications (endlessos.com)
An anonymous reader writes:
Steam and Slack are now both included as Flatpak applications on the Endless OS, a free Linux distribution built upon the decades of evolution of the Linux operating system and the contributions of thousands of volunteers on the GNOME project. The beauty of Flatpak is the ability to bridge app creators and Linux distributions using a universal framework, making it possible to bring this kind of software to operating systems that encourage open collaboration...
As an open-source deployment mechanism, Flatpak was developed by an independent cohort made up of volunteers and contributors from supporting organizations in the open-source community. Alexander Larsson, lead developer of Flatpak and principal engineer at Red Hat, provided comment saying, "We're particularly excited about the opportunity Endless affords to advance the benefits of open-source environments to entirely new audiences."
As an open-source deployment mechanism, Flatpak was developed by an independent cohort made up of volunteers and contributors from supporting organizations in the open-source community. Alexander Larsson, lead developer of Flatpak and principal engineer at Red Hat, provided comment saying, "We're particularly excited about the opportunity Endless affords to advance the benefits of open-source environments to entirely new audiences."
OS nobody has heard of now ships with Steam and Slack... Great.
soylentnews.org
"built upon the decades of evolution of the Linux operating system and the contributions of thousands of volunteers on the GNOME project. "
That seemed kind of unnecessary. Are we going to start announcing all distro news in this way?
I'd query why places think they need to run their business logic in a desktop OS via a word processor's macro language (effectively).
All the office-integration I see looks like it should be no more than a temporary, or rarely used, system of operation.
What kind of things do you script in VBA that you can't do effectively with a dedicated system?
What is this frigging doublespeak that to me seems to say nothing special at all? This especially irks me: "the ability to bridge app creators and Linux distributions using a universal framework, making it possible to bring this kind of software to operating systems that encourage open collaboration".
Exactly - better tools, more suited to the task. And if you're programming in VBA (like the OP), chances are you don't have those better tools.
What job do you need to perform in Word, Excel or Access that can't be done better using something else more suited to the task?
The reason people use them is because they have them there. And then they carry on buying them because they are so accustomed to having them there. On Linux etc. you have OTHER things there. But you're not accustomed to them.
But still, whenever I see an Excel spreadsheet used as anything other than a sheet to tinker in, or Word used as some automated letter-creator from a CSV, or an Access database that sits standalone instead of ODBC to a proper SQL server (of any kind), it makes me wonder why people have done that.
And the reason is "because we already have it, and it can be bodged to do what we're doing today". You can't convert those kind of people to ANYTHING else, even another office suite, while that's true.
It's nothing to do with architectural purity. It's to do with not running your business on the basis of there always being the one guy who understands the VBA code that does something virtually-the-same-but-with-a-tiny-business-rule as everyone else on the planet, coupled with the thing you bought to write letters or check your email.
And, again, I'd question - what business task are you running that requires Office? How often? What does it save? What kind of investment in development? Because putting that investment into proper tools would return dividends, and cost less in the long run.
VBA is job security in places that don't know that they shouldn't be hacking things together in Excel and Access. It's fine for running numbers and interfacing with a proper database, but it's at best an ad-hoc query/reporting/prototyping tool, not a thing for building business-critical processes.
>whenever I see..., it makes me wonder why people have done that.
Because they're not programmers. And they aren't interested in hiring competent programmers to write their mostly-still-trivial "programs", especially since the programmer will often have to expensively recreate a lot of functionality already included in Excel/Word/etc, starting with reading and writing data into extremely complex and poorly documented Office file formats for interoperability with everything else they do.
They write complex monstrosities in Excel, not because it's the right tool for the job, but because it's the only tool they know that's even vaguely appropriate to the job, and they can learn new "tricks" incrementally from whatever place of developmental ignorance they start from. And VBA is an outgrowth of that - a "horrible" language that encourages you to do a whole lot of things in really bad ways, but easy to learn in tidbit-sized chunks when you just need to add *this* little bit of extra functionality beyond what you and your predecessors have already managed to do.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
"Business logic" seems to mostly be code for just that - really basic math (and often convoluted conditionals) that can be implemented (badly) in a spreadsheet (augmented by basic scripting), by people who aren't competent programmers, aren't interested in becoming so, and aren't interested in paying for someone who is to do the work for them.
And lets be honest, that last one is actually a pretty reasonable position considering the difficulty in evaluating the competence and integrity of anyone claiming to be a competent programmer for short-duration contract work.
And frankly the first two are as well - these are people hired as office workers - if they had the skill and desire to become programmers, they mostly wouldn't be there in the first place.
Scripting and "business logic" is basically the badly programmed glue that holds together projects not worth hiring a dedicated programmer for. Or at least that's where it starts, though like any program feature creep feeds its cancer-like growth, potentially fueled by business growth until you've got something so large that it really should be done right, but now it will take years of expensive programmer time to re-implement properly without breaking anything.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
As a programmer, when my wife needed a simple way to track sales for her print business, I gave her an Excel spreadsheet with a few macros.
By taking that shortcut (and using the access management facilities which already exist in Office) I was able to avoid building an entire I/O interface complete with entry forms and reports, didn't have to worry about infrastructure or what the database should look like, and could skip right over authentication. For what amounts to a single user system, it actually makes perfect sense.
This was done done during my workday, it took me about 2 hours; I could have spent a week, full-time, developing the database, implementing a secure authentication system, designing and implementing the forms, designing and implementing the reports, and tweaking all of that until it made sense to the end user, an it would have cost between $2600 and $6000 depending on which client(s) I was setting aside in order to get that done. In the end, I worked two hours extra the day I did it, so it didn't cost me anything; but there's no way I would have put in an extra 40 for that.
Now, when someone's paying me they're gonna get the whole enchilada, because that's what they're paying me for... and because I can bill for it. But, even then there are times when they tell me it's for one person, or one event, or some other single-use reason, and they don't want to pay for it -- I point out how the work may be useful in the future and, when they can show me that it won't be, they get an Office "application" if that's what they're after.
Sometimes the right tool for the job is the tool that can do the job quickly, cheaply, and without requiring a bunch of other tools.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.