Hacker News new | past | comments | ask | show | jobs | submit | more stock_toaster's comments login

Features I would like to see:

* markdown support (for writing/formatting)

* mermaid support (for diagrams)


Just to add a detail, I would also like Markdown support when editing a page. Technically Confluence supports Markdown (or at least it used to) but after you saved the page it converted the content to it's own internal format and the Markdown was gone.

I would also like to be able to update a page through the API. Again, Confluence "technically" supports page editing through the API but it's so cumbersome that it's basically useless. The reason for this request is that we use our wiki to document certain activities (monthly security checks, AWS spend, etc.) and I have to manually update Confluence. It would be so much better if I could write a little Ruby (or Bash, etc.) to add content to a table in a page.


1. You can use Markdown shortcuts.

2. Collaborative editing makes updating content outside the editor tricky. It will work, but not very well. I will consider supporting content updates via the API in a future release.


Hi,

As said in other comments, I work on XWiki. We support Markdown [1] to write documents, among other syntaxes (including (X)HTML), although it's way more limited than our own syntax.

For Mermaid, apparently there are initiatives to integrate it, but nothing finished [2, 3] I guess.

[1] https://extensions.xwiki.org/xwiki/bin/view/Extension/Markdo...

[2] https://github.com/jingkaimori/xwiki-mermaid

[3] https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Merm...


1. You can use markdown shortcuts on the editor. It works.

2. Mermaid support is coming.


> 1. You can use markdown shortcuts on the editor. It works.

Do fenced code blocks work as well?


draw.io is excellent; it stores source code as comments in the PNG/SVG

Perhaps equivalently, use Markdown and store directly in the rendered HTML?


I guess the best way will be to store the PNG/SVG in the storage driver with a reference to it in the editor. The same PNG/SVG will get updated/replaced whenever the code is updated. I need to do more study on this.

Storing the raw data in the editor will bloat the Prosemirror JSON and Yjs state (real-time collaboration) which I want to avoid.


Yep, I think you should store the source file (the .drawio file for drawio) as an attachment of the edited document and call the dedicated editor whenever someone wants to edit it with it, but also save the rendered file to be used to display the result when displaying the document or during regular document edition.


Also an actual monopoly (windows OS).


I’m curious… Why hyper-v and not something like proxmox?


Originally the server & VMs were running on my windows 11 pro dev machine. Keeping HyperV made it easier to move them to another machine.

Now that I have a separate server, I find it easier to develop the VMs on my dev machine, snapshot and then migrate them to the server. I have a library of base images for alpine, Debian & Kali Linux that I can launch as easily as AWS.

Using Hyper-V across both makes this seamless. I can manage the servers using the Windows Management Instrumentation (gui) or RDP into the server.

I know many Linux users have aversion to Windows, but I get a lot of benefit out of Windows for other applications as well (gaming, one drive, document indexing, copilot, as well as all the great native apps)


I wish there were some domestic manufacturers of Kei type cars[1] and, even more so, trucks[2] here in the US (or that it was cheaper and easier to import and license).

[1]: https://en.wikipedia.org/wiki/Kei_car

[2]: https://en.wikipedia.org/wiki/Kei_truck


They are encouraged by regulation in Japan. Lower tax, registration fees, and insurance. Also the requirement in some areas to have off-street parking to register a car is waved.


kebab-case and SCREAMING-KEBAB-CASE are often found in urls too


Alpine has a similar /etc/apk/world file. Further, you can edit this file and then `apk fix` will update the system to reflect any changes.


Microsoft's real users are governments and large corporations -- seat licenses, admin tools, services, etc.

Everyone else using their OS is just another one the products Microsoft can sell to their real users.


It wouldn't be quite so frustrating if it wasn't almost impossible to buy enterprise-equivalent licenses as an individual. Why can't it be as easy as Office 365?

I am mystified as to why Microsoft is so disinterested in taking our money.


So long as you're willing to pay enterprise subscription prices for both Office and Windows with no volume discount, single-user subscription licensing for Windows Enterprise is exactly as easy as subscribing to Office 365:

https://www.microsoft.com/en-us/microsoft-365/enterprise/e3

(click "Try free for one month >", enter an email not already associated with a 365 org, and note that, under "Company size" in the resulting sign-up form, the first option is "1 person")

AFAIK, non-subscription licensing is still as much of a hassle as it's always been — volume licensing, minimum purchases, partners — and the page for a base Windows Enterprise subscription without Office offers "Contact Sales" with no listed price as the only purchasing option.


Also appears to be another one I didn't notice.

https://news.ycombinator.com/item?id=40211891


Maybe Chimera? Probably very friendly for BSD folks since it has a mostly FreeBSD set of core tools (userland).


Chimera is developed by a former Void maintainer. It's still in its infancy compared to the two main "KISS" distributions (Alpine and Void) but it looks promising, especially thanks to dinit, which like S6 is what systemd should have been.

https://chimera-linux.org/docs/configuration/services

Then if a Linux kernel isn't a strict requirement, there's obviously NetBSD, from which Void takes inspiration. At last it's "the real thing" and not some adaptation, and a very underappreciated and overlooked Unix.


chimera definitely goes for its own type of experience, the source of the core tools does not make that much of a difference in that (they were mostly chosen for other reasons anyway)

that said i was a freebsd user for over a decade so it must have left some mark (even though generally the systems have little to do with each other in their general design)


People may not know that you are the creator of Chimera Linux.

There does seem to be a lot of BSD influence over Chimera with the BSD userland, Clang / LLVM toolchain, lack of glibc, and cports.

Regardless of the inspiration, the design choices in Chimera are great. Being able to standardize on things like Pipewire and Wayland without legacy. Working to bring the functionality of systemd without the monolith is great too. I hope Turnstile catches on.


ZFS on Chimera as well of course...


This initially threw me but it appears to be distinct from ChimeraOS, which is described as a, "Steam Big Picture based couch gaming OS".


Yeah, it's an unfortunate name collision. From Chimera Linux FAQ[1]:

The system also has no relation to ChimeraOS, besides the unfortunate name similarity. ChimeraOS used to be called GamerOS and renamed itself to ChimeraOS later; however, at this point Chimera Linux was already in public development with its name in place.

[1] https://chimera-linux.org/docs/faq#what-about-chimeraos


If you always want docs, you just install the `docs` meta package that will pull in any `*-doc` package for anything else you install.


It works similarly in i.e. Debian, so it's not really a quirk of Alpine.


Can you elaborate on what you mean here? I’ve never seen a Debian install packages without docs in 20 years. What have I been doing right/wrong?


If you use a `-slim` debian docker image variant, it won't have the manpages (or most locales, and apt will be stripped down, etc, etc).

I think you can achieve the same thing on bare metal by being careful to tell it not to install a bunch of base package sets.

Alpine is more container-focused than debian, so I imagine they default to something closer to `-slim`, but I haven't tried installing it on bare metal or in a VM.


The "manpages" and any "locale" packages are neither required nor important so are not included in a Debian minbase install. If you want them, you can install them easily with apt.

I'm not sure what you mean by apt being stripped down. You get the normal apt still.


On Debian some packages come with the manual, but have the info-pages as a *-doc (like coreutils), some packages come with basic manual and have extra ones on the doc package (like linux-image), some packages have no documentation at all on the main package (AFAIK nothing on the minimal installation), and some packages bundle everything.


And *-doc packages are not required for their main counterparts.


Thanks, that's exactly what I needed!


This was going to be my inquiry, thanks!


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

Search: