~mlerp

Recent activity

Re: Incorrect markdown parsing 3 months ago

From Filip Jamuljak to ~sircmpwn/sr.ht-discuss

On 10/24/24 3:14 PM, Drew DeVault wrote:
> Hi! We use the standardized CommonMark dialect of Markdown.
> 
That does indeed fix it.

Thanks for pointing that out! I was not aware that there is indeed such 
variance in markdown standards. I will look into making sure my READMEs 
are compliant with one or the other standard from now on.

Incorrect markdown parsing 3 months ago

From Filip Jamuljak to ~sircmpwn/sr.ht-discuss

Greetings,

I have an unlisted project[1] that has a markdown README, which contains 
an installation section which is separated by numbered bulletpoints, 
with code examples below each point.

On website view, however, the README is rendered so that each 
bulletpoint is `1.` , which is not how README is written, or should be 
rendered. I've also tested it with Firefox extension 
GitLabMarkdownViewer[2], and it is rendered fine.

I'm not too familiar with the markdown parser sourcehut uses, but my 
theory is that it uses a simple state machine parser, which is unable to

Re: Thoughts on running my own homeserver 7 months ago

From Filip Jamuljak to ~witcher/public-inbox

First off, I'd like to say congratulations on setting up your own 
homeserver! It's quite honorable in my opinion to seek independence from 
service based web.

Given that you electricity costs are rather high, you might consider 
taking some power saving steps on your system. Seeing that you are 
running 4 full hard drives, I'd focus on that first: I'd recommend you 
look into the `hdparm` command, namely its' `-y`, `-M`, and `-S` flags.

Best regards,
Filip

Re: Payment methods 8 months ago

From Filip Jamuljak to ~sircmpwn/sr.ht-discuss

That is true.

https://sourcehut.org/alpha-details

I must've misunderstood the current state of the project while reading though the blog. oops.

Re: Payment methods 8 months ago

From Filip Jamuljak to ~sircmpwn/sr.ht-discuss

On 6/5/24 1:25 AM, Dimitri Sabadie wrote:
> However, I don’t feel super confident at just sending my credit card
> number, even over TLS. I would have expected a more in-depth
> integration of Stripe, but it still looks like I have to enter some
> HTML forms on sr.ht and, yeah, call me weirdo but I’m not super fond
> of that.
> 

There is a section in the billing FAQ[1] stating that you can get free 
service if you are unable to pay for some reason. Its vague about what 
are the legitimate reasons for getting free service, though they've 
shown to be pretty lax in terms of what they accept as payment[2].

Sourcehut is currently relying on stripe for all its payments, but, as

Re: How to get rid of your advertising revenue by advertising 8 months ago

From Filip Jamuljak to ~mpldr/public-inbox

On 6/3/24 8:38 PM, Moritz Poldrack wrote:
> All of them work, but you're right, I should probably clean that up
> a bit. It reached me at least :D
> 

I was browsing the sourcehut earlier today and yeah, I noticed that 
people here tend to use multiple different emails for different 
occasions. I guess that's one benefit of having your own domain.
I apologize for the spam. I am still quite new to this whole "internet 
but the only account you need is your mail" thing, and honestly, I must 
say, I quite like it! It's very nice not having to click through EULAs 
and cookie usage agreements, and being bound by arbitrary usage limitations.

Anyways sorry for that, it will happen again.

Re: How to get rid of your advertising revenue by advertising 8 months ago

From Filip Jamuljak to ~mpldr/public-inbox

(This mail is meant to be a comment to your blog post)

First of all, your sixth paragraph[1] doesn't finish it's thought.
I also notice that you're referring users on your site on multiple 
different e-mails, when a single e-mail would probably suffice. Namely, 
you're referring users to this inbox on sourcehut, but also on your 
contacts mail on your main page. Worse still, contact you give with the 
shell puzzle on screen is different from that given to the solution you 
link to on onecomplier.com differ! (also I broke your CV: I clicked on it)
regardless, I am Cc-ing this to all of them, just to be sure.

Back to my main comments, although yes, the ad placement on the sites 
you gave as an example is hilariously repulsive, most news sites tend to 
be more moderate about it, balancing it with readability.

Re: C library organization 8 months ago

From Filip Jamuljak to ~sircmpwn/sr.ht-discuss

On 6/1/24 8:19 AM, Drew DeVault wrote:
> then using git-subtree to build a meta-repository that
> brings them together as vendored dependencies and uses recursive make to
> build stuff that depends on these semi-independent projects.
> 
Just looking though git-subtree manpage. This is exactly the thing I was 
looking for! I should really read up the full git documentation someday.
Thanks!

C library organization 8 months ago

From Filip Jamuljak to ~sircmpwn/sr.ht-discuss

I am going to make a C project, hosted on a remote git repository 
(git.sr.ht), but I intend on using one or more C libraries hosted on 
separate git repositories (git.sr.ht or otherwise). Given that these are 
all mine and subject to change, I was wondering what would be the best 
way to place the source and header files, as well compiled binary files, 
so that they could be combined with a toolchain using simple commands 
(git, make, and shell builtins), have independent makefiles, but 
wouldn't necessitate writing to anywhere beyond project folder?

common method I am aware of is writing a makefile that would generate 
library binaries and headers in system 'bin/' and 'include/' folders 
(usually '/usr/bin/' and '/usr/include/'), but that doesn't fulfill my 
requirement of being project local. I was thinking of placing the 
library files in the 'src/' folder, then unpacking them in the project

Re: Build server issue 8 months ago

From Filip Jamuljak to ~sircmpwn/sr.ht-discuss

On 5/27/24 7:36 AM, Sumit Raja wrote:

> Seeing the same issue as well on 3 (private) builds of mine. Jobs are stuck in pending state as well.

I was pondering over it this morning. I don't use the build tool myself 
yet, but I decided to try to help anyways. looking though your build 
log[1], Mr. Gilio, there is no obvious difference between the manifest 
of the job in question[2], and any other jobs you have built beforehand, 
save for the commit link.

given that they're all marked as pending and not failed, I'd reckon it's 
a server side issue.

[1] https://builds.sr.ht/~brettgilio