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.
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
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
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.
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
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.
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.
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!
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
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