Content is like water

Join Our Community

sudo apt purge chromium-browser chromium-chromedriver Bye bye, fake Chromium packages.

Create an /etc/apt/preferences.d/debian-chromium

Debian still maintains Chromium as a regular package in their APT repository. We can configure Ubuntu to get it from there, and continue to receive timely security updates along with all of our other OS updates. This makes sense from a security perspective, since Debian is where Ubuntu already gets most of its packages, and is a very well known high-profile project. There is no need to risk installing software from some random source or telling your system to trust a PPA.

I have nothing against snap in theory, but spamming my mounts, processes, and filesystem is just too darn much

I'm very (VERY!) tempted to use that ppa, but without offense to it's maintainers... it's just some random ppa. If it had more "traction" I'd use it. Right now it has only 3 maintainers.

You can use Chromium from the Debian buster repository.

You can use Chromium from the Debian buster repository. For example, if your Ubuntu release is eoan (19.10):

No, this is not a duplicate of that linked question. I don't need to know "why it's a snap". I want to know how to use it without snap.

"in the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. Applications in this store cannot be patched, or pinned. You can't audit them, hold them, modify them or even point snap to a different store. You've as much empowerment with this as if you were using proprietary software, i.e. none."

What we didn't want it to be was for Canonical to control the distribution of software between distributions and 3rd party editors, to prevent direct distribution from editors, to make it so software worked better in Ubuntu than anywhere else and to make its store a requirement,"

The Mint developers are resistant, though, saying Snap comes with too much Canonical baggage, and in particular seems tied to the official Snap store.

the bloody mount points. I couldn't believe that when I realised what was going on. I got the wire brush and dettol out and scraped it off my drive. Never, ever again.

It won't work if $HOME is not under /home. Really. Not even if you softlink. You need a bind mount

There's a lot of advice online showing how to get rid of snap. (e.g.: https://cialu.net/how-to-disable-and-remove-completely-snaps-in-ubuntu-linux/ worked for me) so the only result (so far, a few months later) is that Chromium has lost a user, and having upgraded Ubuntu since the original Warty, if snap becomes obligatory I'll have to take a look at Mint, or Devuan.

I did the same thing. Another big advantage with Pop! is that it comes ready to deal with modern graphics cards. I coulg get my card working on Ubuntu sometimes, but it had to be done just so, and the phase of the moon needed to be right, or else you had to start the whole process over again. Canonical is free to do whatever they want I guess, but their recent shifts in priorities are a little weird to me.

It is pretty much what Ubuntu 20.04 could have been, but isn't.

I managed to remove it myself this morning...apparently it used to get it's hooks in so deep it was very difficult to remove the daemon as it interconnected with ubuntu-desktop for....reasons.

Good. Hate snap. It's insidious and a pain to deal with.

Plus, have you seen how many loopback mounting points it creates? "df" becomes very hard to use as it buries your actual drives with it's own. One for the daemon, one for GTK, one for Gnome, one for each of the snaps you have installed....

it's an absolute resource hog

Besides running contrary to the principles that lead a lot of people to Linux systems (a closed store that you can't alter...automatic updates you have no control over....run by just the one company)

The strangest "quirk" I had was that I couldn't get the web browser to save a file directly to an attached, encrypted drive. Permissions problem. So I had to save to an interim folder then move it across by hand. Utter pain.

So they want to "reduce fragmentation" OK.

I found that snap can cause lots of issues. I installed keepass using snap, and it installed as a sandboxed app. Very nice for security you would think. Well, a short while later, after 3 upgrades to keepass, it deleted the oldest snap container, which just happened to contain my password file. So secure that even you can't use your passwords now!

Call me cynical, but is Snap possibly a resource hog as well?

Flatpak as a truly cross-distro application solution that works equally well and non-problematic for all

It appears that Canonical is continuing it's vice grip of unliateral, maybe dictatorial control on the development of Snap to the benefit of Ubuntu, but to the detriment of groups like Linuxmint, and all other non-Ubuntu based Linux distributions - like CentOS/Redhat, Suse/openSuSe, Solus, Arch/Manjaro, PCLinuxOS, etc, that are pushing Flatpak as a truly cross-distro application solution that works equally well and non-problematic for all. .

Canonical would do well to make sure they dont complicate things for whatever the next big Linux shift is.

I suspect zerocopy is going to be big, it can significantly improve performance provided you stay in one kernel. If someone can find a way to zerocopy data across containers, in theory you could have data pass through a firewall, nginx, your app tier, into the database and onto the filesystem, without copying it once instead of copying it 8 times.

What's wrong here is Canonical trying to position itself as a powerhouse and ascertain control over Linux users.

If upstream code presumes things will work that dont in snap (e.g. accesses /tmp or /etc) the snap maintainer has to rewrite that code and maintain a fork. Pointless work. Packaging for .deb is a no-brainer.

Why did I put the kdb in the snap file system? Because the app is sandboxed, so I had no choice.

+1 For Devuan here, running it on my home and work machines, and on my son's laptop, despite his IT teacher telling him to install a proper operating system like Windows 10....

>Linux needs an app delivery format Yeah, it's incredible that it has managed to survive for so long without one.

It's Snap that drove me to Arch, so it did me a huge favour. Seeing things like GNOME as a snap and other 'core' products wasn't something I was comfortable with. Personally, I prefer flatpaks as a packaging format when compared to snap and appimage. I agree that Linux needs an app delivery format, but snap's current implementation isn't it.

I run a fairly ancient RedHat Enterprise 6 on my 32-bit test machine and if I need something requiring Gtk3 (such as a latest Firefox or Chrome), I just make a chroot and use debootstrap (from EPEL) to get me a Debian 9 userland for that program. Easy. No bizarre "app stores", no conflicting packages. Do people use Snap app-stores because they don't know how to use the chroot command? Or are they just lazy? If it is because they want the added security of a container, substitute chroot with lxc... Shouldn't be necessary though; if you avoid non-ethical software (i.e App-stores), you are very unlikely to need the added security.

I've already said this, but if you think the average desktop computer user thinks a sentence beginning "I just make a chroot..." makes any kind of sense, you haven't been paying attention to the level of intelligence of the general public.

Well, that user can safely stay with Windows. Hiding these things from me makes wish that.

Google / DuckDuck are your friends.

By design, snap apps have no access to /etc. They live in their own little world, but instead of a normal chroot, they are splatted all over the standard Linux filesystem layout. With other bits mounted hither and thither. Its a mess, and subject to change with each release.

You stick with what you know. It's trouble free because you know how to use it. That's achievable on any of the main OSs, even (gasp!) Windows.

Linux on the desktop won't take off until it is equally easy. Snap may be dumbed down, restricted and all the rest of it, but for ordinary users it's easier - and more secure - than the alternative.

>We do want Linux to be mainstream, don't we? Not at any cost.

The cost of snap is too high. Its Linux ffs. We want it lean, mean, open, stable, file based, and bash friendly. We want our tools to work together, and above all, we want choice. Snap is none of that.

See also BMW and Tesla owners. If Tesla does become the largest US-based carmaker, many of the buyers will, I'm sure, think of reasons to move onto something else.

Its not too complicated but it is an annoyance. I want /etc/hosts, /etc/resolv.conf, /etc/nsswitch.conf, /etc/rc.local and all the standard stuff to work. The heavy lifting is done in the kernel. All they need to do is leave it alone. Its getting harder to make Ubuntu behave like Linux.

Did my first Xubuntu 20.04 LTS last month: no (dependency) trouble at all to remove snap and its systemd tentacles...

My biggest issue with snap is not the concept per se but that it's a mostly Ubuntu thing and FlatPak and AppImage are similar ideas. For once it would be nice if the Linux world would consolidate around a single technology instead of fragmenting like this.

Good for the likes of Mint to say NO.

Canonical are really taking whole chapters out of the Microsoft 'How To' book. Do it our way or not at all.

Dll hell was caused by multiple apps on the same device requiring different versions of dependencies. As dlls were shared that couldn't be resolved. Giving each app it's own versions of its dependencies is a way of avoiding dll hell. I'm not saying this a good thing but it avoids that specific problem.

The worst thing about snap is that it runs contrary to the concept of shared libraries that are easy to upgrade. Each snap package includes the dependencies for the app, which means you may have multiple (vulnerable) versions of a library installed. It's DLL hell all over again from a security perspective.

if it's not broken, fix it until it is.

However at the end of the day I'll stick with whatever Mint decides is best for me. Year in and year out I enjoy a stable, reliable, and consistent environment that "just works" and which thankfully shows very little change between versions. I appreciate that I can pick up a new (to me) laptop and have Mint installed and configured to suit my needs in less than fifteen minutes. And that thereafter I can ignore it, let updates install without worries, and trust that it won't suddenly break itself. Our household includes my two Mint boxes, two Windows 10 laptops, and a shiny new iMac. I'll leave it you to guess which computers have the least issues.

Devuan +1 I've been running it on my main laptop, a local server and a whole bunch of Pis since "ASCII". Recently migrated to "Beowulf" (which incidentally was released yesterday) and was blown away by the speed & quality improvements. It's a superb distro - and I've tried a few, including Ubuntu, Xubuntu, Mint, Alpine, Debian, Red Hat, and others I can't remember

The past few years seems to have be a race between Microsoft and various players in the Linux world to see who can produce the worst abomination of a UI. It's as if there's been a ritualistic burning of the UI design rule book that led to many years of largely stable and consistent user experience across all platforms

Hey, Mint, team! Switch your upstream to Devuan. Because every week, I'm thinking about switching directly there myself...

the Mint team remove all the bad stuff added by Canonical and add better desktop environments. You should try it, you never know, you might like it...

big companies feel more confident if the Linux distribution is being backed/supported by a known commercial entity.

definite good news, as it will hopefully have a ripple effect on crappy chipset makers, getting them to design and test their hardware with Linux properly, for fear of losing all potential business from Lenovo.

I suppose it means 2 things, first, you get official support and warranty, and second, the distros will be Secure Boot approved in the UEFI, instead of distro makers having to figuratively ask Microsoft for pretty please permission.

A bind mount is basically where you mount a given directory on top of an existing one. Suppose you have a RAID array where you have a partition mounted at /home2, containing some larger user accounts. If you wanted to remount /home2/user to /home/user (to sidestep issue #1), without the issues that come along with symlinks (it is not a directory, just a token that points to it), you'd do something like mount --bind /home2/bob /home/bob and the directory will then be traversable from both locations. The target folder must exist, same as any mount point. The end result is somewhat similar to a symlink, but instead of creating a special filesystem object, it utilizes the operating system's filesystem mounting machinery to do it, which makes it more transparent to running software. Tools like 'du' and 'find' will still be aware that they are cross filesystem boundaries, and will also behave as such if the bind mount is entirely within a given filesystem. Finally, as they're transient by nature (unlike symlinks), they need to be placed in fstab or some startup script to make them persistent.

If we're not careful, it could become the new 'systemd' problem It probably already is. I don't want to sound too Stallman, but this is the inevitable "company" influence you'll always have. Companies do have their objectives which they will pursue determinedly, since they are not philanthropic (no judgment, just observation). Systemd and Red Hat. Nvidia and their drivers. Google and Android. Apple and iOS. Manufacturers with MS only support. And Canonical also has a history there: the Amazon links, Unity, Mir, and now snap.

Do Not Disturb Get rid of any and all notifications for however long you like. Cast out ye heathens, for there is many a work to be done!

Automatic firmware updates can be accessed from your software settings on System76 hardware. These updates help to promptly quash any threat of security risk to your computer.

Init Freedom is about restoring a sane approach to PID1 that respects portability, diversity and freedom of choice.

It's like patting your head and rubbing your belly, but you're jogging.

Your cat watches (cat not included)

Note that that browser support for these values is nuanced. For example, space-between never got support from some versions of Edge, and start/end/left/right aren’t in Chrome yet

I think you’re missing the spirit behind the classic “centering is hard” complaint in a couple of places, which, at least for me, always comes back to not knowing the height of the elements.

Maybe $$slots like $$props? My use case is that I'd like to wrap a slot's content in an element that applies styling that I'd like absent without the slotted content. Something like this: {#if $$slots.description} <div class="description"> <slot name="description"></slot> </div> {/if}

Moving DOM elements around made me anxious and I wanted to preserve natural tab order without resorting to setting tabindex, so I also made a flexbox version that never moves DOM elements around. I think it's the superior solution, at least for the layouts I was going for. https://github.com/wickning1/svelte-components/blob/master/src/FlexCardLayout.svelte

<Masonry> component implementation could be something like this (very drafty)

The CardLayout creates a store in context and the Card creates a standardized div container and registers it to the store so that the CardLayout has access to that DOM element. Then in afterUpdate you can move the DOM elements into columns and Svelte will not try to put them back where they go. It's a bit messy but it works.

It isn’t always guaranteed to be a single root element, in that case it could return an array of elements?

I think that maybe instead of using the prefixed $$ globals, a more "natural" solution could look something like this: import { slots, props, parent } from '@component';

allow <slot> to be part of a slot

But it doesn't work so I have to wrap slots in useless and interfering divs or spans like this: <Button fz="16" h="64" {...$$props}> <span slot="prepend"><slot name="prepend" /></span> <slot /> <span slot="append"><slot name="append" /></span> </Button>

I want to make some add-ons or wrappers on components e.g BigButton.svelte <script> import Button from './Button.svelte' </script> <Button fz="16" h="64" {...$$props}> <slot slot="prepend" name="prepend" /> <slot /> <slot slot="append" name="append" /> </Button>

Related to #1824, can do <svelte:component this={Bar}> <slot></slot> <slot name="header" slot="header"></slot> </svelte:component> <script> import Bar from './Bar.svelte'; </script> as a forwarding workaround

Interesting . That feature (<slot slot="..."/>) was only recently added in #4295. It wasn't primarily intended to be used that way, but I guess it's a good workaround for this issue. I'm yet to find caveats to slotting components that way, other than it's inconvenient, as opposed to <Component slot="..."/>.

I'm not sure I understand the point of what you're trying to do. Components inherently have no root node so there isn't just one "node slotted" that you could possibly reference. <slot slot=""> doesn't create a wrapper around your component in the DOM. It just injects your component as Svelte usually would.

The extra div soup is two fold:

(this issue)

A component reserving a slot but needing to perform manipulation on its content dom reference will need to add an extra element wrapper on the receiving site (some people mention it here: #2106).

A big app will have lots of components compared to regular html elements and these need to be wrapped before being fed to a slot, every single time on the call site

If components gain the slot attribute, then it would be possible to implement the proposed behavior of <svelte:fragment /> by creating a component that has a default slot with out any wrappers. However, I think it's still a good idea to add <svelte:fragment /> so everyone who encounters this common use case doesn't have to come up with their own slightly different solutions.

This syntax easily provides all the features of components, like let: bind: and on:. <svelte:fragment /> is just a component with a special name.

If there's a slot attribute that works for elements and (eventually) components, when the desire to pass a component or multiple nodes into a named slot without a wrapper inevitably arises then this syntax seems like a natural extension.

I think this is very important feature to implement. Because for now we need to wrap target components by useless wrapper nodes.

Another possible syntax is {#slot bar}<Foo/>{/slot}, which would also allow a bunch of DOM nodes and components inside the slot, without them needing to be from a single component

Ahh ok, it's a regular let. It's too bad it has to be so intrusive on the call sites.

The <svelte:self> element allows a component to include itself, recursively. It cannot appear at the top level of your markup; it must be inside an if or each block to prevent an infinite loop.

It must be called during the component's initialisation (but doesn't need to live inside the component; it can be called from an external module).

beforeUpdate(async () => { console.log('the component is about to update'); await tick(); console.log('the component just updated'); });

Since this is a recursive component I can imagine it being tricky to oversee all the slots and props passing.

// read-only, but visible to consumers via bind:start export let start = 0;

export const start = 0

export let start = 0

<svelte-virtual-list-row>

Starter: Free offering that lets you try out DOCR.

Simple answer: If you need the interface in in another module.

Just use import type {AnimType}... instead

export 'InterfaceName' was not found in

Basically the typescript compiler emits no code for interfaces, so webpack can not find them in the compiled module; except when a module consists of only interfaces. In that case the module will end up completely empty and then webpack will not investigate the exports.

On the linked thread I've put details, a suggestion for implementation and an offer of help if someone wants to submit a PR. Let's see what happens!

The behavior of this code is identical, but the implementation is much easier to write and read.

While custom iterators are a useful tool, their creation requires careful programming due to the need to explicitly maintain their internal state. Generator functions provide a powerful alternative: they allow you to define an iterative algorithm by writing a single function whose execution is not continuous. Generator functions are written using the function* syntax.

While it is easy to imagine that all iterators could be expressed as arrays, this is not true. Arrays must be allocated in their entirety, but iterators are consumed only as necessary. Because of this, iterators can express sequences of unlimited size, such as the range of integers between 0 and Infinity.

Can I use the title attribute?Yes. The content prop can be a function that receives the reference element as an argument and returns a string or element.tippy('button', { content(reference) { const title = reference.getAttribute('title'); reference.removeAttribute('title'); return title; }, });The title attribute should be removed once you have its content so the browser's default tooltip isn't displayed along with the tippy.

v1 tabs tightly couple to their v1 Cache; v2 tabs tightly couple to their v2 Cache. This tight coupling makes them “application caches.” The app must be completely shut down (all tabs closed) in order to upgrade atomically to the newest cache of code.

In my opinion, this single-tab Refresh behavior strongly violates the principle of least surprise, and it doesn’t help us to maintain code consistency or data consistency.

Think about how native apps work in your favorite desktop operating system. Er, no, not that one. Think about your favorite popular desktop operating system.

They say that there are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors. Caching is what Service Workers do. It’s literally the #1 hard thing! … or maybe the #0 thing? Whatever. It’s hard.

If a Service Worker fails, it’s possible to break an entire website in ways that we can’t fix on the server side (or at least, not right away). Imagine this: your site appears to be down, but refreshing the page won’t help, because the browser isn’t even talking to your server; it’s just talking to your broken Service Worker.

As programmers, we sometimes have to work on tricky stuff, but then we say, “Well, it’s not rocket science.” But Service Workers are rocket science.

Oh, silly me, that won’t work. We can’t update index.html at all, so we certainly can’t remove the call to register!

Service Workers are the hot new thing in web APIs. They’re designed to be like the HTML5 Application Cache, but without being objectionable.

“So, what do you do then?” “Oh, I’m the LocalStorage” he replied, shuffling uncomfortably. “I provide a scripting interface for text storage maintained across pages and browser sessions.”

I am trying to implements this usecase (a generic lazy loader component which forwards slots/events to the "real" component).

In 3.29.0 you can now use <slot slot='...'> to forward slots into a child component, without adding DOM elements.

Would love to see passthrough slots to create superset components, for example Table and TableWithPagination (table slots for TableWithPagination could be passed through to Table).

From a community POV, Svelte Summit should probably be mentioned, the YouTube channel has most of the recordings uploaded as standalone videos now (there is a playlist here ).

I would love to see this features as well, since it makes component composition and reuse a lot easier.

the behavior you want happen is actually a chicken and egg situation, you need to initialise FancyList in order to get the value for let:prop from the FancyList, however you can't initialise FancyList without the value of id which comes from within FancyList.

It's highly recommended you inspect a tippy element via your browser's DevTools. An easy way to do this is to give it hideOnClick: false and trigger: 'click' props so that it stays visible when focus is switched to the DevTools window.

The CSS automatically gets injected into <head> with the CDN (tippy-bundle). With CSP enabled, you may need to separately link dist/tippy.css and use dist/tippy.umd.min.js instead.

TylerRick

Your operating system: Ubuntu 18.04.4 LTS

What I think is happening is that instantiating the component is immediately running the $: reactive code, which dispatches the event synchronously, before the parent component attaches the listener.

Thanks to that I have chance and time to properly initialise all the properties without reactive calls and I do not have to ignore these "initialising" events before proper initialisation.

Now I think it's valid behaviour that reactive statements are not running until onMount is fired.

I've reproduced, in a very simple way, what I would like it to do: https://svelte.dev/repl/2b0b7837e3ba44b5aba8d7e774094bb4?version=3.19.1

I don't know what I'd expect this to do, if not create an infinite loop. You're asking Svelte to do something before every update, and one of the things you're asking it to do is to flush any pending changes and trigger an update.

Can't find the Svelte way of doing this, setTimeout helps now, but this is not a good way working with a framework I think.

Or just watch the value with a reactive statement instead of an event handler on the input like: $: inputValue, onInput() This is a good solution and seems to work in all cases.

TylerRick

The alternative is uncontrolled components, where form data is handled by the DOM itself.

In a controlled component, form data is handled by a React component.

I mean the second one

The third other syntax in your update compiles because Svelte doesn't see that as a conditional bind:this, but as an attribute called bind:this that is conditionally applied. All directives need to be visible at compile time.

Knowing exactly what happens in your application can mean the difference between feeling in full control or experiencing deep frustration. Personally, unknowns drive me crazy, which in turn often leads to all sorts of experiments and/or debug sessions.

Note that the value of canvas will be undefined until the component has mounted, so we put the logic inside the onMount lifecycle function.

It's more powerful to have them happen in definition order, because this lets you intercept thing in event handlers or in actions.

Also as an aside, your REPL is far, far too complicated. You've got a much better chance of us being able to see your issue and fix it if you boil it down to just the minimum required code in order to reproduce the issue.

If you're using webpack with svelte-loader, make sure that you add "svelte" to resolve.mainFields in your webpack config. This ensures that webpack imports the uncompiled component (src/index.html) rather than the compiled version (index.mjs) — this is more efficient.

I figured I could try making my own with modern technologies.

The CSS Zen Garden era was hugely inspirational to many.

Monaco is what VScode, and CodeSandBox, use for code editing. It's obviously one of the best code editors in the world. It's always been on my want-to-try-list and this is the perfect proejct.

But Svelte doesn't work like that - all css is statically compiled, and changing myCSS doesn't update the head component.

I wanted to use GitHub Gists which are a wonderfully low friction way of sharing code

I wanted to update it to JAMstack

And this way also fits more with data down, actions up.

So you might ask what is the benefit of using the event dispatcher over just passing a prop down? In some scenarios, you will need to add an action to a button that is 3 or more components down and passing a prop all that way is considered prop drilling (it is frowned upon by some, meh each to their own). However in the case of using an event dispatcher, even though these events don’t bubble, we can easily pass them up using a shortcut that Svelte has.

With this setup, we can create a default action that should take place if one wasn’t passed down.

Depending on what other component libraries you’ve used, you may be used to handling events by passing callback functions to component properties, or using a special event syntax – Svelte supports both, though one is usually more appropriate than the other depending on your situation. This post explains both ways.

It’s something that we’re already used to do naturally with HTML elements. Let’s demonstrate how using the <slot> component works by building a simple Card component

While this tutorial has content that we believe is of great benefit to our community, we have not yet tested or edited it to ensure you have an error-free learning experience. It's on our list, and we're working on it! You can help us out by using the "report an issue" button at the bottom of the tutorial.

But that method has its limitations. The <slot> directive cannot be dynamic.

You should default to the most permissive option imo and there really is no reason to check anything until you really need to If it were left to me I'd just use optional chaining, as it also eliminates the need for no-ops

In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.

be conservative in what you do, be liberal in what you accept from others