Makaqu Networking on DC
Makaqu Networking on DC
Suddenly, this question came to my mind: is networking possible in the Dreamcast with Makaqu or other ports?
Check the readme files.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
-
- Posts: 268
- Joined: Tue Nov 24, 2009 2:20 am
- Contact:
That makes perfect sense. Why read a simple text file with a simple text editor when you can read a complex document with flashy colours in a complex web browser.ceriux wrote:i think anytime someone makes a project, they should make a small page with an online readme that opens with in that projects page. i'd probably read the readme's then. i just hate reading out of text files.
Get off my lawn!Ken Thompson wrote:One of my most productive days was throwing away 1000 lines of code.
Reason #1 would be because people don't read readme files. It might be a simple text file in a simple text editor, but 95% of the time you're wasting your time and energy writing it because it won't be read. You could write any old rubbish in there and I can guarantee that most people will never even be aware of it. Forget about security, readme files are probably the safest place in the world to stash confidential or personal info.dreadlorde wrote:Why read a simple text file with a simple text editor when you can read a complex document with flashy colours in a complex web browser.
Reason #2 would be because many people who write readme files can't even get basic stuff like using the correct line endings right. I've lost count of the number of times I've downloaded a Windows executable, opened the readme file and seen Unix line endings. Sloppy work, and doesn't exactly fill me with confidence that the product was properly tested on it's target platform either. Basic HTML, for all it's faults, is at least reasonably sane and standardised by comparison.
Reason #3 would be because a document on the web - wait for it! - need not be complex, flashy or colourful. This was a strawman argument against, so you'd need to come up with something better.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
-
- Posts: 368
- Joined: Thu Jun 25, 2009 4:45 am
- Location: Michigan
Re: Makaqu Networking on DC
Not yet, however I'm working on a way to network it and avoid requiring PPP support, BlueCrab says he thinks it will work, so I'm expecting a good outcome.JasonX wrote:Suddenly, this question came to my mind: is networking possible in the Dreamcast with Makaqu or other ports?
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Huh... There's no such thing as "Unix line endings". In Unix, Linux and others OSes, a line break is signaled with the '\n' (0xd). However, there is a "DOS/Windows line ending", where the line break is signaled by TWO characters, '\n' and '\r' (0xd and 0xa, respectively). Every current *nix text editor I used in the last 10 years or so can handle both formats in a seamless way; the same cannot be said about Windows Notepad, which is unable to understand this complex concept of line breaks with just a single char. Oh, well...mh wrote:I've lost count of the number of times I've downloaded a Windows executable, opened the readme file and seen Unix line endings. Sloppy work, and doesn't exactly fill me with confidence that the product was properly tested on it's target platform either.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
Either/or, it doesn't matter what I call it, you know what I'm talking about anyway.
Incidentally, there's no such thing as DOS/Windows line endings either, and Unix was certainly not the first OS to adopt a line-ending convention.
The CR/LF convention came from emulating teletype machines, DOS inherited it's convention from CP/M (which copied the teletype emulation convention) and Unix from Multics. Modern Windows (which - let's be clear - has absolutely no relationship whatsoever to DOS) is just following the CP/M standard.
None of which excuses the shocking disgrace of Windows notepad of course, which is one reason why I always keep a shortcut to Wordpad in my "Send To" menu; it has no problems recognising them.
And nor does it excuse the developers I was talking about from not getting the line endings right in the readme.
Incidentally, there's no such thing as DOS/Windows line endings either, and Unix was certainly not the first OS to adopt a line-ending convention.
The CR/LF convention came from emulating teletype machines, DOS inherited it's convention from CP/M (which copied the teletype emulation convention) and Unix from Multics. Modern Windows (which - let's be clear - has absolutely no relationship whatsoever to DOS) is just following the CP/M standard.
None of which excuses the shocking disgrace of Windows notepad of course, which is one reason why I always keep a shortcut to Wordpad in my "Send To" menu; it has no problems recognising them.
And nor does it excuse the developers I was talking about from not getting the line endings right in the readme.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
-
- Posts: 268
- Joined: Tue Nov 24, 2009 2:20 am
- Contact:
"Correct" line endings? Your mean a carriage return and then a new line? Talk about going back to the days of teletypes and typewriters!mh wrote: Reason #2 would be because many people who write readme files can't even get basic stuff like using the correct line endings right. I've lost count of the number of times I've downloaded a Windows executable, opened the readme file and seen Unix line endings. Sloppy work, and doesn't exactly fill me with confidence that the product was properly tested on it's target platform either. Basic HTML, for all it's faults, is at least reasonably sane and standardised by comparison.
Reason #3 would be because a document on the web - wait for it! - need not be complex, flashy or colourful. This was a strawman argument against, so you'd need to come up with something better.
Something better: Keep it simple stupid. Why would someone go to a website to essentially read a readme file if the won't even read the readme? Not everyone downloads software from where it was created.
Get off my lawn!Ken Thompson wrote:One of my most productive days was throwing away 1000 lines of code.
Context - line endings that are correct for the target platform.dreadlorde wrote:"Correct" line endings? Your mean a carriage return and then a new line? Talk about going back to the days of teletypes and typewriters!mh wrote: Reason #2 would be because many people who write readme files can't even get basic stuff like using the correct line endings right. I've lost count of the number of times I've downloaded a Windows executable, opened the readme file and seen Unix line endings. Sloppy work, and doesn't exactly fill me with confidence that the product was properly tested on it's target platform either. Basic HTML, for all it's faults, is at least reasonably sane and standardised by comparison.
Using CR/LF actually has a lot of advantages; not least that it's also compliant with RFCs 821, 1939, 2060 and 2616. Unix also actually does use CR/LF for on-screen display; it's only for storage where it just uses LF (it converts from LF to CR/LF when displaying). So it's storage of plain text files on Unix that is actually the odd one out. Some more interesting history and discussion here: http://blogs.msdn.com/b/oldnewthing/arc ... 91899.aspx (by somebody who is namechecked as a contributor by Linus in the Linux kernel 1.0 docs, so he's knows what he's talking about from both sides of the fence).
OK, that's a valid enough reason, but I can think of reasons why an online readme might be preferred by many. Hyperlinks is one, bookmarks is another, searching and indexing is a third.dreadlorde wrote:Reason #3 would be because a document on the web - wait for it! - need not be complex, flashy or colourful. This was a strawman argument against, so you'd need to come up with something better.
Something better: Keep it simple stupid. Why would someone go to a website to essentially read a readme file if the won't even read the readme? Not everyone downloads software from where it was created.
Either way it still doesn't excuse the author from not having used line endings that are correct for the target platform.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Interesting stuff. Visited the link. I always wondered what the carriage return was for. Prior to that, I thought a carriage return was silly and seemed to only make text document compatibility a pain in the arse.mh wrote: Reason #2 would be because many people who write readme files can't even get basic stuff like using the correct line endings right. I've lost count of the number of times I've downloaded a Windows executable, opened the readme file and seen Unix line endings. Sloppy work, and doesn't exactly fill me with confidence that the product was properly tested on it's target platform either. Basic HTML, for all it's faults, is at least reasonably sane and standardised by comparison.
I guess there was a reason for it back in the day. Dot matrix printers or whatever the deal was back in the day.
/Honestly I've got no idea what TextPad and WinMerge do to line endings nor do I think about whether or not my readmes are "Notepad" compatible. I may be guilty.
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
No Dreamcast homebrew software was ever able to connect to the Internet via dial-up, due to the lack of a PPP stack in the DC modem's KallistiOS driver.
There are many homebrew programs that uses the broadband adapter instead, but this adapter is so expensive and rare there's no point in supporting it, due to the extremely limited userbase. Well, actually I'd implement support for it anyway if there weren't higher priorities in my list.
However, BlueCrab certainly knows a lot more about DC networking than I do, so good luck. Networking via dial-up Internet is something the DC homebrew scene always needed.
There are many homebrew programs that uses the broadband adapter instead, but this adapter is so expensive and rare there's no point in supporting it, due to the extremely limited userbase. Well, actually I'd implement support for it anyway if there weren't higher priorities in my list.
However, BlueCrab certainly knows a lot more about DC networking than I do, so good luck. Networking via dial-up Internet is something the DC homebrew scene always needed.
-
- Posts: 368
- Joined: Thu Jun 25, 2009 4:45 am
- Location: Michigan
It avoids using PPP, think "system link" and your on the right track.mk wrote:No Dreamcast homebrew software was ever able to connect to the Internet via dial-up, due to the lack of a PPP stack in the DC modem's KallistiOS driver.
There are many homebrew programs that uses the broadband adapter instead, but this adapter is so expensive and rare there's no point in supporting it, due to the extremely limited userbase. Well, actually I'd implement support for it anyway if there weren't higher priorities in my list.
However, BlueCrab certainly knows a lot more about DC networking than I do, so good luck. Networking via dial-up Internet is something the DC homebrew scene always needed.