sparky

joined 2 years ago
MODERATOR OF
[–] sparky@lemmy.federate.cc 6 points 2 hours ago (1 children)

I’m not aware of any EU companies that actually manufacture drives. Just a few like Synology who rebadge JP made drives.

[–] sparky@lemmy.federate.cc 2 points 2 days ago (3 children)

Is it run out of a private residence? How could it happen if it’s in a real data center…?

[–] sparky@lemmy.federate.cc 16 points 3 days ago (3 children)

Seems pretty clear to me. Why would you risk your life if the army doesn’t even want you there?

[–] sparky@lemmy.federate.cc 10 points 3 days ago (1 children)

Yes, Steam takes a cut as well. But the crux of the argument is the monopoly part. You can distribute your game outside of steam - on other app stores, or sell it directly to customers if you want. On iOS, there is literally no other distribution channel. You have to pay Apple and use their thing. That’s the difference.

[–] sparky@lemmy.federate.cc 5 points 1 week ago

For what it’s worth, this is also my understanding, as the administrator and operator of this Lemmy instance.

[–] sparky@lemmy.federate.cc 15 points 1 week ago

Well not to split hairs, but seeing as they are currently perpetrating Second Holocaust, it would have to be more like Third Holocaust. But the problem with the Israeli comments is that unarmed civilians aren’t very effective at holocausts.

[–] sparky@lemmy.federate.cc 5 points 1 week ago* (last edited 1 week ago)

HA-HA, I TOO INGEST CARBOHYDRATES FOR SURVIVAL THROUGH MY FACE ORIFICE. I THEN TRANSPORT MYSELF WITHOUT A SOURCE OF ELECTRICITY. IT IS INDEED CONVENIENT TO BE A BIOLOGICAL BIPEDAL ORGANISM.

[–] sparky@lemmy.federate.cc 37 points 1 week ago (3 children)

As it happens, you shouldn’t trust Lemmy DMs either, as they’re not encrypted and can be read by instance administrators. So don’t use them to say anything that you wouldn’t be okay making public.

[–] sparky@lemmy.federate.cc 6 points 1 week ago (1 children)

Well it’s gonna learn to post crypto spam ads and swastikas then. Which come to think of it.. might be the point

[–] sparky@lemmy.federate.cc 18 points 1 week ago* (last edited 1 week ago) (1 children)

The entire summary on Wikipedia is sales guy bullshit. It’s barely comprehensible.

allowing businesses to streamline their operations, improve customer engagement, and make data-driven decisions. The platform is highly customizable, enabling organizations to tailor it to their specific needs and industry requirements. Dynamics 365 is designed to help businesses unify their processes, gain insights into their operations, and foster better relationships with customers.

Bruh you dropped this: ^synergize^

[–] sparky@lemmy.federate.cc 18 points 1 week ago (5 children)

What the fuck does Dynamics do? Is it some kind of shitty database?

[–] sparky@lemmy.federate.cc 1 points 1 week ago* (last edited 1 week ago) (1 children)

So far I think I can live without Topaz, Photoshop and some other image stuff long term, but to be honest if that turns out to be wrong, I’m inclined to buy a cheap Mac Mini specifically for photo stuff rather than keep Windows around anymore.

 
 
 
 
 

Apparently this is the name of a construction/engineering firm here in Lisbon Portugal. Amusing coincidence

 

The main Fediverse community for Europe is located at !europe@feddit.org - please don’t submit many new posts to this sub on Lemmyworld. We are considering the board to be sunset and in a transition period for the next few weeks, after which it will be locked for new posts. Thanks.

 

Is there an equivalent to doing /u/user in The Bad Place, to notify and summon someone?

 

Just thought I'd share this since it's working for me at my home instance of federate.cc, even though it's not documented in the Lemmy hosting guide.

The image server used by Lemmy, pict-rs, recently added support for object storage like Amazon S3, instead of serving images directly off the disk. This is potentially interesting to you because object storage is orders of magnitude cheaper than disk storage with a VM.

By way of example, I'm hosting my setup on Vultr, but this applies to say Digital Ocean or AWS as well. Going from a 50GB to a 100GB VM instance on Vultr will take you from $12 to $24/month. Up to 180GB, $48/month. Of course these include CPU and RAM step-ups too, but I'm focusing only on disk space for now.

Vultr's object storage by comparison is $5/month for 1TB of storage and includes a separate 1TB of bandwidth that doesn't count against your main VM, plus this content is served off of Vultr's CDN instead of your instance, meaning even less CPU load for you.

This is pretty easy to do. What we'll be doing is diverging slightly from the official Lemmy ansible setup to add some different environment variables to pict-rs.

After step 5, before running the ansible playbook, we're going to modify the ansible template slightly:

cd templates/

cp docker-compose.yml docker-compose.yml.original

Now we're going to edit the docker-compose.yml with your favourite text editor, personally I like micro but vim, emacs, nano or whatever will do..

favourite-editor docker-compose.yml

Down around line 67 begins the section for pictrs, you'll notice under the environment section there are a bunch of things that the Lemmy guys predefined. We're going to add some here to take advantage of the new support for object storage in pict-rs 0.4+:

At the bottom of the environment section we'll add these new vars:

  - PICTRS__STORE__TYPE=object_storage
  - PICTRS__STORE__ENDPOINT=Your Object Store Endpoint
  - PICTRS__STORE__BUCKET_NAME=Your Bucket Name
  - PICTRS__STORE__REGION=Your Bucket Region
  - PICTRS__STORE__USE_PATH_STYLE=false
  - PICTRS__STORE__ACCESS_KEY=Your Access Key
  - PICTRS__STORE__SECRET_KEY=Your Secret Key

So your whole pictrs section looks something like this: https://pastebin.com/X1dP1jew

The actual bucket name, region, access key and secret key will come from your provider. If you're using Vultr like me then they are under the details after you've created your object store, under Overview -> S3 Credentials. On Vultr your endpoint will be something like sjc1.vultrobjects.com, and your region is the domain prefix, so in this case sjc1.

Now you can install as usual. If you have an existing instance already deployed, there is an additional migration command you have to run to move your on-disk images into the object storage.

You're now good to go and things should pretty much behave like before, except pict-rs will be saving images to your designated cloud/object store, and when serving images it will instead redirect clients to pull directly from the object store, saving you a lot of storage, cpu use and bandwidth, and therefore money.

Hope this helps someone, I am not an expert in either Lemmy administration nor Linux sysadmin stuff, but I can say I've done this on my own instance at federate.cc and so far I can't see any ill effects.

Happy Lemmy-ing!

 

Just thought I'd share this since it's working for me at my home instance of federate.cc, even though it's not documented in the Lemmy hosting guide.

The image server used by Lemmy, pict-rs, recently added support for object storage like Amazon S3, instead of serving images directly off the disk. This is potentially interesting to you because object storage is orders of magnitude cheaper than disk storage with a VM.

By way of example, I'm hosting my setup on Vultr, but this applies to say Digital Ocean or AWS as well. Going from a 50GB to a 100GB VM instance on Vultr will take you from $12 to $24/month. Up to 180GB, $48/month. Of course these include CPU and RAM step-ups too, but I'm focusing only on disk space for now.

Vultr's object storage by comparison is $5/month for 1TB of storage and includes a separate 1TB of bandwidth that doesn't count against your main VM, plus this content is served off of Vultr's CDN instead of your instance, meaning even less CPU load for you.

This is pretty easy to do. What we'll be doing is diverging slightly from the official Lemmy ansible setup to add some different environment variables to pict-rs.

After step 5, before running the ansible playbook, we're going to modify the ansible template slightly:

cd templates/

cp docker-compose.yml docker-compose.yml.original

Now we're going to edit the docker-compose.yml with your favourite text editor, personally I like micro but vim, emacs, nano or whatever will do..

favourite-editor docker-compose.yml

Down around line 67 begins the section for pictrs, you'll notice under the environment section there are a bunch of things that the Lemmy guys predefined. We're going to add some here to take advantage of the new support for object storage in pict-rs 0.4+:

At the bottom of the environment section we'll add these new vars:

  - PICTRS__STORE__TYPE=object_storage
  - PICTRS__STORE__ENDPOINT=Your Object Store Endpoint
  - PICTRS__STORE__BUCKET_NAME=Your Bucket Name
  - PICTRS__STORE__REGION=Your Bucket Region
  - PICTRS__STORE__USE_PATH_STYLE=false
  - PICTRS__STORE__ACCESS_KEY=Your Access Key
  - PICTRS__STORE__SECRET_KEY=Your Secret Key

So your whole pictrs section looks something like this: https://pastebin.com/X1dP1jew

The actual bucket name, region, access key and secret key will come from your provider. If you're using Vultr like me then they are under the details after you've created your object store, under Overview -> S3 Credentials. On Vultr your endpoint will be something like sjc1.vultrobjects.com, and your region is the domain prefix, so in this case sjc1.

Now you can install as usual. If you have an existing instance already deployed, there is an additional migration command you have to run to move your on-disk images into the object storage.

You're now good to go and things should pretty much behave like before, except pict-rs will be saving images to your designated cloud/object store, and when serving images it will instead redirect clients to pull directly from the object store, saving you a lot of storage, cpu use and bandwidth, and therefore money.

Hope this helps someone, I am not an expert in either Lemmy administration nor Linux sysadmin stuff, but I can say I've done this on my own instance at federate.cc and so far I can't see any ill effects.

Happy Lemmy-ing!

 

Just thought I'd share this since it's working for me at my home instance of federate.cc, even though it's not documented in the Lemmy hosting guide.

The image server used by Lemmy, pict-rs, recently added support for object storage like Amazon S3, instead of serving images directly off the disk. This is potentially interesting to you because object storage is orders of magnitude cheaper than disk storage with a VM.

By way of example, I'm hosting my setup on Vultr, but this applies to say Digital Ocean or AWS as well. Going from a 50GB to a 100GB VM instance on Vultr will take you from $12 to $24/month. Up to 180GB, $48/month. Of course these include CPU and RAM step-ups too, but I'm focusing only on disk space for now.

Vultr's object storage by comparison is $5/month for 1TB of storage and includes a separate 1TB of bandwidth that doesn't count against your main VM, plus this content is served off of Vultr's CDN instead of your instance, meaning even less CPU load for you.

This is pretty easy to do. What we'll be doing is diverging slightly from the official Lemmy ansible setup to add some different environment variables to pict-rs.

After step 5, before running the ansible playbook, we're going to modify the ansible template slightly:

cd templates/

cp docker-compose.yml docker-compose.yml.original

Now we're going to edit the docker-compose.yml with your favourite text editor, personally I like micro but vim, emacs, nano or whatever will do..

favourite-editor docker-compose.yml

Down around line 67 begins the section for pictrs, you'll notice under the environment section there are a bunch of things that the Lemmy guys predefined. We're going to add some here to take advantage of the new support for object storage in pict-rs 0.4+:

At the bottom of the environment section we'll add these new vars:

  - PICTRS__STORE__TYPE=object_storage
  - PICTRS__STORE__ENDPOINT=Your Object Store Endpoint
  - PICTRS__STORE__BUCKET_NAME=Your Bucket Name
  - PICTRS__STORE__REGION=Your Bucket Region
  - PICTRS__STORE__USE_PATH_STYLE=false
  - PICTRS__STORE__ACCESS_KEY=Your Access Key
  - PICTRS__STORE__SECRET_KEY=Your Secret Key

So your whole pictrs section looks something like this: https://pastebin.com/X1dP1jew

The actual bucket name, region, access key and secret key will come from your provider. If you're using Vultr like me then they are under the details after you've created your object store, under Overview -> S3 Credentials. On Vultr your endpoint will be something like sjc1.vultrobjects.com, and your region is the domain prefix, so in this case sjc1.

Now you can install as usual. If you have an existing instance already deployed, there is an additional migration command you have to run to move your on-disk images into the object storage.

You're now good to go and things should pretty much behave like before, except pict-rs will be saving images to your designated cloud/object store, and when serving images it will instead redirect clients to pull directly from the object store, saving you a lot of storage, cpu use and bandwidth, and therefore money.

Hope this helps someone, I am not an expert in either Lemmy administration nor Linux sysadmin stuff, but I can say I've done this on my own instance at federate.cc and so far I can't see any ill effects.

Happy Lemmy-ing!

view more: next ›