Hacker Newsnew | past | comments | ask | show | jobs | submit | dspillett's commentslogin

> therefore most likely overpriced at ~6€/month

> something where security is high and support is 24/7 available

You are not going to get great 24/7 support inside anything like €6/month (though many may promise it!), so that service may not be as overpriced as you think.

Another thing to consider is that many VPS providers have “dirty” IP ranges so you will have trouble with getting your mail delivered. A common solution to this is to use a mail delivery service (like mailgun, mxroute, and many others) so your mail comes from a managed “clean” source and has less chance of summarily being declared spam just from the source address alone (these services also reduce the need to think about spf/dkim/etc and keep an eye out on changes that may happen in that realm). Essentially by self-hosting a service like this, you are taking back the admin of managing all that so you have to ask yourself if it is worth saving a few € per month, and consider what you might lose if something goes wrong and all your mail starts bouncing.

> switch to some VPS/root or anything where I can SSH and install, compile my own services

Be wary of most really inexpensive options here. In most cases you will experience performance degradation (at random times, or just almost always) and other issues due to noisy neighbours on oversold infrastructure.

> I really want to try this, but I'm afraid my DNS will be blacklisted if I do.

The best (but unfortunately time-consuming) way to get comfortable with this is probably to register a sacrificial domain and set it all up for that domain on hosts not associated with your domains that normally send mail. Play with it, break it, fix it, break it again, etc., until you feel confident you aren't going to screw yourself by trusting your own admin of all this on a domain that actually matters.


That depends on what you mean by “real game dev”. I did a few game things of my own in BBC BASIC, eventually with a bit of 6502 assembly in key places, back in the day. On those machines you can still happily run a basic game loop in interpreted BASIC, the whole thing for text-based games, you just need to get down to the bare CPU for things like sprites, other rapid graphics drawing, and maybe some other number crunching (I did some basic compression in assembly for lots of text, though it wasn't really effective, if you are already doing graphics in assembly, then it probably makes sense to do collision detection and such there too, etc.).

C64 BASIC is kind of a mess, there's zero support for graphics and sound. Your code rapidly becomes a giant pile of POKEs and PEEKs, and all your operations become absurdly slow because all the math routines are floating point only, so there's a ton of integer/fp conversion overhead on something as simple as "peek a memory location, AND/OR it with a few values taken from variables stored as floating point, poke it back".

Assembly becomes really attractive really quickly.


> C64 BASIC is kind of a mess, there's zero support for graphics and sound.

Which is surprising because one of the advantages of the C64, IIRC, for games was that it had built in sprite manipulation so you didn't have to do the work yourself on the CPU (unless you wanted something more flexible than the one standard sprite format).


C64 Basic did have integers.

A floating point

A$ string

A% int

as you would expect ints are quicker.


Not on C64 BASIC. C64 BASIC converted ints to floats internally and converted them back to ints when needed.

What sidestepped part of that conversion was using variables instead of literal constants. So, doing something like N0=0, and using the variable N0 instead of 0 was faster.

Additionally, C64 looked up variables in the order they were defined, so variables defined later were slower. If your program used 0 a lot, you'd want to have N0=0 as the first statement in your program. I typically had N0=0 and N1=1 as those were common to use.

QBasic was so much faster and implemented differently. DEFINT A-Z at the top of the program typically sped it up significantly if you didn't use floating point. This might have worked on GW-BASIC as well.


Err, ints are internally stored as floats as well and that leads to some really interesting performance quirks where you'd not expect.

There were BASIC compilers for C64 which generated significantly faster code just because they actually used ints for integer operations.


BBC BASIC was far better than C64 BASIC.

It had a nice set of built-in graphics functions and an inline assembler, amongst other things.

I can still remember that VDU 23 was the command to redefine a character, so much easier than doing the same sort of thing on the C64 (copy the character set from ROM to RAM, get the VIC to use the RAM copy with POKE statements, modify the desired character)


> It had a nice set of built-in graphics functions

IIRC those were actually in the “OS” ROM, with BASIC just having syntactic sugar to call them, rather than being part of the BASIC ROM itself, so you could call them from elsewhere (i.e. your own assembly code, even if you'd paged the BASIC ROM out to make some RAM available in that bit of the address space on the BBC Master).

> and an inline assembler, amongst other things.

That assembler was great when I was cutting my programming teeth and progressing a bit beyond BASIC to better understand the hardware.

BBC BASIC has some other crucial, more basic, features that were missing from other 8-bit micros. Actual named functions and procedures were key¹, and long variable names were useful² where some BASICs only allowed one or two characters³.

--------

[1] Other BASICs had no more than GOTO and GOSUB/RETURN, usually only allowing you to jump to line numbers, not names/labels. There was even some support for local variables making proper recursion possible up to a point (limited by the small stack).

[2] if limiting for long code due to memory constraints

[3] or allowed more but only respected the first couple, BBC BASIC syntax in theory allowed up to 248 characters⁴ but only respected the first 40 and practically you still limited yourself to a few (say, up to 10 for some for clarity, 1 for things like loop counters to save space in your code, CPU time in the interpreter, and space in the interpreter's variable dictionary).

[4] the absolute limit to what you could actually use in a line, itself having a length limit of 256-minus-a-few, and at that length all you could do was assign a single digit or print the value.


C64 Basic was V2 of a dialect of the Microsoft derived Basic for the PET. It was out of date already compared to the latest V4 because the older version fit into a smaller ROM to save costs.

> because of economic pressures

Self-hosting isn't relevant here anyway. When discussing the hoovering up of information irrespective of licences to produce the model, where the model is finally run isn't significant.

You might not be paying the industry pirates-at-scale to run a model on their hardware, but you are still using the same information, irrespective of the same desires of its creators, the same way, just in a different location.

Heck, local hosting might even be making the situation worse if people are trying to train their own model because they are then likely to be scraping data too, and becoming part of the army of bots that are pushing hosting costs up and forcing everyone to use tricks like PoW scripts that can inconvenience human readers as much as the scrapers.


> You might not be paying the industry pirates-at-scale to run a model on their hardware, but you are still using the same information, irrespective of the same desires of its creators, the same way, just in a different location.

For individual use I personally think it's ok. Access to information shouldn't be penalized or regulated, but distribution should. So in this case it's relevant where a bootleg model is run.


> > which have indexed all of the books and used pirated copies to do so

> Funnily enough, people on HN often do not consider this an issue, like at all...

That is far from true - opinion is quite divided, perhaps even close to 50/50. It sometimes seems that the opinion is skewed massively towards the positive because there are a lot more “look what I did with GenAI” stories because “yeah, I'm not doing that because… here's what I did the old way” doesn't catch interest in the same manner.

This is one of the (several) reasons I'm doing my level best to avoid using the tools - I don't want to pay in to the companies that have run ripshod over everyone's work because they can¹. This is a rather risky position to take in a company where the up-aboves have all but said “get with AI or get left behind”, but quite frankly at the moment “redundancy” isn't a scary word for me².

--------

[1] Take from a few (i.e. download a couple of TV shows) and it is piracy making you liable for huge fines or even prison time, take from practically everyone (hoover up all their published writing irrespective of licence, gum up their servers with your badly written, or well written but deliberately badly behaved, scraper, etc…) and that is perfectly valid for training purposes.

[2] I appreciate that for many this is not the case, and because of economic pressures they might have to compromise on their feelings if they have the same opinions as I do on GenAI.


>That is far from true - opinion is quite divided

That might be true if you look further into it. I am a casual frontpage reader and the frontpage usually is plastered with AI stuff. Either new bullshit benchmarks, AI workflows, AI editor updates, AI company did something bad (again), or cool(?) projects people vibecoded. I also had arguments about AI used for art on here before and my personal experience usually is people defending their slop art.


> That might be true if you look further into it.

You don't have to look much further into it. If you aren't making that much effort it is hardly anyone else's fault that you've got an inaccurate impression of how things are.


For that much functionality 98kb is hardly bloated at all by modern standards, impressively slight in fact, it could probably cope with some more.

Unless part of your fun is keeping it so very trim, of course!


Yes, it's part of the fun. Original version was 65kb (with just the single editor mode and all the filters, mp3/wav export etc). But then having to add flac codec, tempo estimators and finally the multitrack mode, made it closer to 100.

When I started developing I was a little frustrated with how bloated the web felt back then so I took that direction, it's much better today though and it's no longer an issue, but I still find it fun to impose these constraints and try to work within or around them (there's this fascinating concept of constrained creativity)


I appreciate the attention to efficiency and avoiding bloat. As a frequent audacity user I'm thinking I might end up using this for a lot of simpler tasks.

That said the web offers such great techniques to maintain this. Passive loading of plugins for example could keep things snappy and light and load things when you need them.

If you want the perspective of a prospective long term user: I'd be very comfortable using your app even at tens of megabytes. You could probably keep your initial load pretty light but pull in larger modules as needed. There are certain effects and audio layering I often use in Audacity that would keep me there, but your modern interface and browser access are huge selling points. If your vision includes moving to a bigger editor I guarantee you you'll find a huge base who wouldn't even notice megabytes of code.


All very good points, not much to say I agree with you. With loading plugins on demand it could grow in size without affecting load and experience (and since offline mode is a separate link that would still be fine to be a little larger since it's fetching the app locally).

There was a good theatre adaption of The Machine Stops by a UK group called Pilot Theatre (I saw it at York). They performed it as a live Youtube broadcast during the faf of 2020, though I can't see it listed anywhere now. Worth having a look for if you have better sources than mine. I must have a scan of my media array later, to see if I downloaded a copy I can rewatch.

Thank you I will look for it.

https://archive.ph/x3wgL if you want to read without finding and clicking the "no, your interest in stalking me is not legitimate" box that is nested in extra clicks for each of the partners (seriously wordpress, if you are happy to be so significantly non-compliant just be honest and don't comply at all).

I block the consent banner. Easiest way to avoid such immoral practices.

I tend to assume that because the “legitimate interest” options are on by default, despite everything else being off if it is, that they are opt-outs rather than op-ins, and therefore blocking the banner just removes my chance to opt out.

I instead just paste wordpress links into archive.* or similar without going in personally at all.


My cynical view is that a lot of these outlets would have liked to block the archive anyway⁰ but didn't as it could look bad to do so, and AI scraping is a convenient excuse. Much like some (but far from all) of the recent job cuts that have been announced “due to AI”.

An even more cynical view is that the information on many local news sites in recent years isn't worth archiving anyway, it is largely generic rubbish filtered down from on high because these days most local outlets are owned by large national groups¹ that use them for little more than a place to insert adverts.

For actual local news, which those outlets do sometimes still carry, archiving personal blogs, event sites, and some social media content³, would be more useful than local news outlets. It is a shame that a lot of this has moved to platforms that are more difficult to archive (distraction media providers block the archive too, discord and similar services are more difficult to easily/meaningfully archive, heck searching for non-recent information on them that you know is there can be a pain, etc.)

--------

[0] For numerous reasons including some idea that it could affect their advertising revenue, that they don't want things which they correct [because they are actually wrong or because those higher up the ownership chain are happy with certain truths] are embarrassingly preserved in their original form, etc.

[1] Like Reach Plc or Newsquest¹ (which owns the most prominent local rag where I live) in the UK.

[2] Which is in turn owned by the US company USA Today Co.

[3] Though this is probably largely blocked from the archive too.


> But FUSE is pretty annoying to use on Mac – you need to install a kernel extension, and Mac OS seems to be making it harder and harder to install kernel extensions

I'm not a Mac user at all, so there may be reasons what I'm about to suggest is silly beyond the ones I will mention myself, but…

Another way around this is to run the FUSE filesystem in a small VM running a different OS that is more FUSE friendly, then export that filesystem to MacOS using a network filesystem that it natively understands. This may also be NFS so you aren't avoiding NFS if so, but you at least separate the NFS issues from the issues interfacing git (assuming interfacing git with FUSE doesn't have just as many gotchas as using NFS directly).

There are a couple of obvious potential performance issues here. Firstly adding the extra network filesystem layer will likely add a noticeable amount of latency for all operations. You likely have this twice too: if you are reading a repo from the host machine rather than checking out its own copy (which would likely be a significant inconvenience) then the VM will need to access that somehow. Secondly any caching in RAM that the fs->git layer does will mean allocating enough RAM to the VM for that which will be dedicated so not available to other processes on your bare metal. If the amount of memory required is small anyway then this is not a problem, or if letting it swap out to disk (or using a disk based cache in the first place) is significantly less inefficient than constantly rereading+reprocessing the structure that the cache is intended to speed references to, then that is an option too.


The blog post is from 2023, one year later she would have gotten FSKit with Sequoia.

https://developer.apple.com/documentation/fskit


> And yet I look at all the money being shuffled around between Nvidia and Google and Microsoft and Amazon and Apple

A lot of that is “weird money” created by the act of passing it around between the entities or “Holywood accounting” style money that exists when convenient and will vanish the instant it might be taxed or need to be extracted from the cycle to pay for something tangible. Trying to use a large amount of that money for tangible long-term building projects risks piercing the vail.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: