should we create an OS development magazine?

[01000101]

It doesnt even have to have OS in it or even programming at all.

it could be called The Underground, due to the nature of low-level coding and the fact that we (as a community) are not that well known.

I also do infact like OSDev Weekly as well.

BTW, thank you Yayyak for the generosity.

[JackScott]

I like The Underground, though it does sound a bit like a skateboarding magazine.

No probs for the server. It's not doing much else at the moment.

[os.hacker64]

1337, Elite

[Alboin]

I like The Underground, though it does sound a bit like a skateboarding magazine.

Ditto.

[Solar]

I have worked on two fanzine projects, as well as an online website, as editor, and "been close" to more than one print magazine that came, bloomed, and died. Most of you will know my way of "spoiling the fun" at the beginning, to see if an idea survives some discouragement. You don't have to convince me here, you have to convince yourself that my criticism does not apply to you. If, after going over my post, you still feel like doing it, then by all means go ahead.

----

1) Someone tosses in a general, not very detailed idea. Several other people get rather excited over the idea, toss in a couple of not-too-detailed ideas of their own, say "let's do it" and, next thing, try to come up with a cool-sounding name. No-one has provided much detail, no-one has actually commited to doing anything (like, chief editor, proofreader, webhoster, technical writer, the one that answers the email, ...). Does this kind of "lets-do-it-oh-you-mean-me-no-I-can't" remind you of something? It does remind me of my OS project, which saw interesting, extensive discussions on what could be done, but went flatline the moment it came to doing the actual work.

2) For this kind of not-news, technical-oriented publication, come up with a "table of content" for the first six issues of your magazine before you even begin working on the first one, to make sure you actually have enough stuff to make it more than a one-time thing. Always stay ahead at least two issues' worth in TOC's, four is better, so your articles aren't written on a whim, but well-researched. Give your TOCs some structure (e.g., languages & toolchains, debugging tricks, theory, ...) to avoid being "all over the place". Agree on a schedule for releasing articles - after it's been written, it has to be proofread, there's layout to be done...

3) Ask yourself if you really want to add this kind of long-term project to your schedule. A magazine is merciless. The next issue deadline is always on the horizon. You will constantly have to worry about when to write that essay or article. Actively worry, as in, you cannot wait until inspiration strikes and there's time to spare, you have to write that darn thing. And then the next one. For years to come. You will be at the mercy of your release schedule (and that of your co-editors). Or you don't agree on a regular release schedule, which means the whole thing is stillborn anyway.

4) Ask yourself why no-one of the "old farts" around here has jumped on the topic...

That's it from me. Err, and no, I don't want to work on this project. Not because I wouldn't find such a magazine interesting, or because I couldn't write a good article or two on the subject, but because I don't want to load such a project on my timetable.

[JackScott]

1) If nobody else puts up their hand, I am willing to do all the editing, web hosting, and publishing myself. I have a group of people that owe me a year's worth of proofreading. I'd appreciate not having to write ALL the articles, though.

2) Good point. Which is why we've already tried coming up with possible articles. If people commit and say "I can write X by Y", then it should be possible to come up with both a release schedule and a few TOCs.

3) I've been editor for a semi-professional quarterly magazine before (for a year, i.e. four issues), and I know the workload involved. It is a lot, I'll admit. But not so much that a small team of individuals working in their spare time can't achieve. A good point is that you are better off with 3 more dedicated people than 12 "oh yeah, why not, let's go along for the ride" people. Brooke's law applies to magazine production teams as well.

4) Too busy working on their insane post counts.

[Combuster]

4) Too busy working on their insane post counts.

Which means, reading all threads at the very least. Hey it's a post where I wrote only one line. Cheap post count


EDIT:
Seriously, like solar said commmitment is a problem. My schedule density is like a sine wave (Mainly due to colleges). Which means I interestingly look at what happens here, but not offer any help until there's at least some maturity in the project. A lot of things are hyped before and during release and then can't meet the expectations.

[AndrewAPrice]

What I would like to see in the magazine:
- Reviews of operating systems (e.g. one a fornight, or if the magazine is only published twice a year review 6 or so an issue). With screenshots, personal opinions, overall rating, etc.
- Theoretical discussions (e.g. comparison of different forms of IPC, or how a certain device works). Use operating systems as examples and describe how the implement the different forms, etc. Theory about overhead, future extensibility, etc.
- User submitted reviews/articles. Possibly viewed (and moderated) by Quality Assurance first to make sure they meet publishing standards.

What I would not like to see:
- Beginner tutorials (e.g. step-by-step tut on setting up the GDT). Topics like this are really basic and countless tutorials online cover them. This wouldn't interest the medium to senior OSDev'ers (your main audience) since these topics make up less than 1% of most of our OS's. Tutorials are generally bad anyway, since every OS is different therefore cannot be followed step-by-step. (This doesn't mean you can't have an article about the GDT - but it would be more appropriate to discuss the reason behind it, common ways of implementing it, tips and tricks and more complex issues/solutions for more advanced readers, etc.)
- Just in plain ASCII. The Postscript and PDF formats are portable, and most people are using or have access to an OS environment which can read these formats. LaTeX is another option, as most LaTeX compilers can generate plain text, PS, and PDF files at the change of a few compile switches. This would make it more convenient for the reader (it is available in multi-formats) and for the publisher.

[Solar]

LaTeX is another option, as most LaTeX compilers can generate plain text, PS, and PDF files at the change of a few compile switches.

Indeed LaTeX is a powerful intermediate format. However, not too many people know how to process it (into text or PDF), and not too many people know how to generate it, either (as opposed to people who can write ASCII or turn some pages from their favourite word processor into PS / PDF). Personally, I'd be stumped both ways - I wouldn't know how to write LaTeX, nor how to read it. (Aside from reading it in source, of course.)

[01000101]

What I would not like to see:
- Beginner tutorials (e.g. step-by-step tut on setting up the GDT). Topics like this are really basic and countless tutorials online cover them

I partially agree here. I agree to the fact that they have been beaten to death with the tutorial stick, but at the same time, we are trying to encourage higher-level programmers to 'cross the threshold', so basic tutorials would seem useful to entice them to even start working on the most basic of kernels.

To satisfy our more senior-developer readers, much more difficult tutorials could be set in place, or different things that only more accomplished programmers could use such as GUI-related articles and advanced task managment or the like.

I would agree to aiding in either a bi-weekly or monthly magazine release due to me being in college and not always having the time within one week to actually sit down and type something useful.

Solar is right though, the name should come last, the team managment phase should begin and workloads should be assigned to make sure people will stick to what is demanded.

[Alboin]

I do think we should follow Solar's advice and go full throttle with a 6 issue list of material.

Gathering ideas would appear to be the next step in that direction. Here are a few possibilities.

• A series on quantum computing and the future of the osdever.
• A comparison of shell interfaces, focusing on largely unknown shells, and even commercial ones. (eg. powershell.)
• A piece on VM based OS's, with examples.
• Something (Maybe a series?) getting really in depth with the theory of GUI design.
• A short piece on SFS.
• OS protection schemes, and their actual merit. (eg. machine code verification.)
• Safe System's Programming Languages

[Dex]

I would like to see articles on stuff you can not get info on easily. here's a list of stuff i could write articles on ( Note: some would take, a number of articles to cover them ).

Implementing a USB stack.
Implementing a TCP/IP stack.
Implementing a high-res GUI.
How to port Fasm to your OS.
Writing a ARM OS.
Writing a web browser, for your OS.

[inflater]

I like step by step tutorials (where everything is explained why it belongs here and there) especially for OSdev... like the bran's kernel development tutorial.

[Zacariaz]

1. Wow, i knew i'd been away for a while but 4 pages since friday?

2. What i would like see in a magazine it articles not only conserning osdev, assembly, C and so on, but many sorts of articles, new programming languages, articles about various architectures, news, ideas, weird workarounds, encryption algorhitms, and so on. Basicly a magazine which takes the regular computer magazine to the next level, focusing on other issues than the mhz race, ms office, latest games and such. I think that an effort should be done to enable regular people to understand the contents, this will allso provide more readers. I allso think that anyone should be able to contribute, that is if the editor in chief finds the material good enough.

3. I could host the magazine on my server @ www.g33kz-inn.org and i would of course do so for free.

4. I wouldn't mind (actually i would love too) doing my part contributing various services, but i don't ecactly know what it should be, i guess maybe i could manage the web site.

[Solar]

Nice to see my criticism is taken positive (the way it was meant).

One more thing: Step-by-step tutorials do not belong into a magazine. They are only possible when starting from a well-known platform, i.e. bootloader, building a cross-compiler, stuff like that. Readily available on the internet, and not much of a problem for the experienced developer anyway.

Once you get beyond "beginner land", you no longer have a common denominator to build upon. All you can do is compare concepts, possibly with examples. (Interrupt / SYSENTER / SYSCALL, you get the idea.)

Such a magazine would be for the midrange-to-experienced developer. One who has read (and understood) "The C Programming Language", the manuals of his toolchain, and at least the first volume of the Intel Manuals. Minimum.

It keeps stunning me how friendly we - as a community - are towards people who start programming "their first OS" who don't even have a solid understanding of pointers, their compiler, or how a OS is structured. (Those who are surprised they don't have printf() at their disposal, or that malloc() is mainly done in userspace.) It would be a shame wasting the kind of manpower a magazine requires on what I essentially consider "script kiddies". (No offense to present company.)