intc

Simple C based approach on Sieve of Eratosthenes (by yours truly):

* https://github.com/intc/c-notes/blob/master/threads/4-thrd_e...

One can use standard IMAPS/SMTPS/PGP compliant native email app with C1.FI.

I'm still contemplating about the E2E webmail app - No matter which way one looks it - It's a shaky concept...

BTW. Does anyone know what is the current state of WASM Constant Time proposal?

Ms Luke said hackers took control of her PayPal account, in a credential stuffing attack that affected 35,000 PayPal customers in December.

https://www.abc.net.au/news/2023-07-25/byron-bay-data-breach...

Have you checked the MS powershell approach[1]?

1. https://learn.microsoft.com/en-us/microsoft-365/enterprise/u...

We use server side spam filtering at c1 (see: https://c1.fi/about/). So far things are working pretty well but certainly false positives may occur. On the positive side client can contact yours truly and we can usually do something to sort these out.

Thanks fore commenting! The public informative parts of c1.fi are readable without JS. See https://c1.fi/about?lang=en for example.

Registering, account management etc. will require JS - Simply to provide better UX.

There are no 3rd party libraries or references (except on pages handling payments via Stripe) in use and the JS is not minified. No 3rd party trackers either.

Our self hosted email service, https://c1.fi, works fine with "plus addressing".

In addition I recently laid out plans for "disposable aliases" with a machine generated random string as local part for users in our shared domains (like c1to.me). So one could use an alias when signing-up with a service. Once the service is not relevant - Just delete the alias. All comments and suggestions are welcome. =)

https://archive.ph/yblJk

Can you email me? Perhaps I can help. Contact information available here: https://c1.fi/about?lang=en (scroll down the page)

I ported the HelenOS kernel to RV64 in 2016, but I've never properly finished the user space support. I hope this board will be a good motivation for me to finally push the entire OS to the same level as x86-64

https://twitter.com/mdecky/status/1397892220225736711

Same but 2004: https://www.openbsd.org/images/rack.jpg

We still are fighting the oligopoly with our vaulted c1.fi email service. Please feel free to check us at https://c1.fi/v/hn20220905/?lang=en.

Here's EU's JRC-MECSA report on our service: https://mecsa.jrc.ec.europa.eu/en/finderRequest/b5daceffc76e....

Support for client's own domain is currently under works. Our webmail supports PGP and one can use IMAPS/SMTPS or ActiveSync based native email clients too.

All servers self hosted (we run C1/Gentoo!) in our own computing facility in Finland. =)

C1.fi is a simple Finland based email service which supports using standard IMAP and ActiveSync clients. We encrypt all messages with account holder specific keys before storing them on servers mass storage. -- antti@c1.fi

c1.fi (an email service yours truly is providing) supports SMTPS, IMAPS and ActiveSync. https://c1.fi/v/hn519/about?lang=en

Thank you for tour feedback! Valid point.

For the time being one can access pricing information after creating the free trial account.

I'll add some way of presenting the most common pricing options along with the other service information.

"By itself, WebAssembly cannot currently directly access the DOM; it can only call JavaScript, passing in integer and floating point primitive data types. Thus, to access any Web API, WebAssembly needs to call out to JavaScript, which then makes the Web API call. Emscripten therefore creates the HTML and JavaScript glue code needed to achieve this."

Quoted from: https://developer.mozilla.org/en-US/docs/WebAssembly/Concept...

Via https://github.com/mbasso/asm-dom? (for example). For every complex self generated challenge there is an even more complex solution?

Of course it is. In most cases you do not have any sort of guarantees regarding the browser (which it self usually is more complex piece of software than all your operating system and it's accessories calculated together - difficult to audit - known to collect metrics etc etc). In addition one can sandbox their local terminal pretty effectively - With Tomoyo or some other MAC technology. It's not so bad idea to actually isolate your browser too (with Mandatory Access Control) - It usually has no business for a global view on your filesystem or local network resources.

I personally don't appreciate the idea of using Rust as an overall "only solution" replacement. Requires LLVM (a huge overkill on a system otherwise based on GCC), no proper support for dynamic linking, own build system, absolutely huge "ecosystem", No standardization (-> no competing implementations), SLOW to compile... Yada-yada.

Rust it self also has it's fare share of free after use etc bugs. Please check: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Rust

I'm personally thankful that we have SQLite which is written in C - It's efficient, tiny and severe bugs are relatively rare.

As the original article quotes: “What I cannot create, I do not understand.”

I think PGP is fine for encrypting some files. But you should take into consideration that when you encrypt a file it's very likely that some (or all) of the plain text is left behind on the block device. Using full disk encryption (LUKS for example) will give additional protection (so one can't read plain text fragments from the device when it's not "open").

Some issues with LaTeX development are essentially intractable.

Could you perhaps open this claim a little? What's wrong with the L3 programming layer? (https://www.alanshawn.com/latex3-tutorial/ - Already integrated to the format)

This is a worrisome trend. Now one needs to manually check what the build system will fetch (and from where) before starting the build.

Many times most of the dependencies are available through the package manager of ones system.

A good way in my opinion is just to provide a clear list of the dependencies and make the build system complain if it's not there so one can install it (if didn't bother manually to check that the listed dependencies are present).

Of course there are very large and complex projects which may need more sophisticated solutions - Perhaps some sort code notarisation would serve well? Yet even there the dependency management should be clearly separated from the build system and it should prioritize using system provided packages when possible.

There are probably other considerations and implications too. Like preference of static linking over dynamic etc..

Could you explain (in simple terms if possible) how the Multicore OCaml achieves a memory model which is much simpler on more efficient than in Java or C (mentioned at https://github.com/ocaml-multicore/ocaml-multicore/wiki)?

Didn't see any mentions of critical sections (mutexes) with C++ examples in the documentation ("Bounding Data Races in Space and Time"). I'm not sure I understand the comparisons the writers are presenting.

Well. I usually work on system programming but recently started to code a web app (Account manager at c1.fi - Golang, JS, HTML, CSS) and I can say that creating even most simplistic & light weight web app can be rather demanding job. Especially when you need it to render and behave well on both desktop and mobile! =)

We are soon opening https://c1.fi - Horde webmail (https://wm.c1.fi) can do this.

(Preferences -> Mail -> Composition -> Default method to compose messages: "Plain Text")

Perhaps 6 - 7 years ago we provided some one U server for a client. Initially the server worked fine. Then we upgraded it's disks (originally 80 gigs or so) to 1TB each (in RAID1 configuration).

After the new disks were installed the server started to have multitudes of issues with disk performance and random read / write errors.

I think it took us several days to understand that the new spinners where much more sensitive than the original ones - And the large (very powerful) fan (located between the hdds) emitted too much vibration for the disks to operate properly.

We ended up swapping the chassis to one with radial fans. Problem solved.

https://fennosys.fi/

We have Linux on all desktops and laptops. This has been the case for more than 10 years by now. There are still a couple Windows VM's (mainly for checking how some things work on Windows in case need be).

In my personal opinion it's not very advisable to run binaries "from somewhere". Some views regarding flatpak: https://www.flatkill.org/2020

Dynamic linking is a Windows term (thus .DLL). In Linux (and *BSD) the same concept is know as shared libraries.

If you force everything to be static in a system then yes - You need to statically link everything you need into your interpreter too. Things are going to grow in size a lot (and spinning up your interpreter will take longer time too).

I personally think that shared libraries are the way to go in most cases. And there are distributions which handle this quite well. Of course simplification and general gravity towards minimalism will help too.

Using FFI is extremely handy (very fast to experiment against some dynamic library when the need arises). I personally think your point is perfectly valid.