I tend to agree, the potential issue is power consumption (which tends to be higher with x86/x86_64.) My old AMD K5 with 32 Mb RAM, two ethernet cards and a wireless card served me for many years. It was running a minimal Debian with iptables & ssh. I never measured power consumption, but I'd wager it was higher than an off the shelf router.
Will you please provide a link to the $1.95 developer board? I'm only finding PIC chips for that price and not a full boards like the Launchpads & Arduinos.
If you're up to 2GB you're likely seeing a leaky plugin. Firebug, for me, seems to leak. In short, if you're seeing consistent ram usage > 500MB, you should try with all plugins disabled or in safe mode.
I'm at just over 59 hours, and it's at about 400MB* on a 64 bit Arch Linux desktop. That goes out the window when Firebug is on. It seems to leaks memory like crazy. It can easily climb over 1.5GB* in only a few hours of debugging/development.
For OOP though, the terchniques are the same for C++, Java and C# so unless you want them to learn the C#/.NET specific parts (eg WPF, WCF, all the wizard generated bumpf) then or learn how to use Visual Studio, you might as well show them Java instead. The tooling should be better for your platform and I'm sure you can find better example code.
Well, if "MS doesn't make.NET for (his) platform", Visual Studio is totally out of the question. He's most likely on a *nix; so, he'd most likely go with something like MonoDevelop (GTK#) for an IDE and one of these may be chosen for a GUI toolkit (when he eventually gets to that): http://www.mono-project.com/Gui_Toolkits
If he wants to stick with Pascal, he could also consider Oxygene which also runs on top of the CLR/Mono. This has the advantage of using all the classes already available in Mono, but with a similar syntax.
I like the fuzebox project. But that's a 8-bit console. That is never gonna sel massively.
But I guess you were talking about community driven hardware and gaming system. I am still not sure these guys will leave well as well. Why haven't we seen a linux ARM-based or x86 based open gaming system appear ? That's basically, buy a computer and 2 USB gamepad and plug them on your TV. the software is mainly written in the GeeXbox. Still no one knows about it ?
I'm not going to say it's a realistic alternative to the current generation consoles, because it's most likely going to appeal to a similar niche market as the Uzebox (Note, the Fuzebox is a specific implementation of the Uzebox.)
*shrugs* I may not like it, but that's just how things are currently.
The part of the review I found to be quite funny was this line:
if the Department of Defense wanted to rip off a Windows theme to make their software seem familiar to their employees, why did they pick a look from fifteen years ago?
I guess the reviewer never tried IceWM before since it's looked pretty much exactly the same for about 10 years now.
I think the fact that Andrew Tanenbaum riduculed Linux in 1993 for being an "outdated architecture", when Minix just got paging working last year after 20 years of development, encapsulates my point completely.
MINIX 1 & 2 were teaching tools. MINIX 3, which is "loosely based somewhat on previous versions of MINIX," wants to not only be a teaching tool, but also be a serious option for small & embedded systems. Also, this new version of MINIX has only been in active development for about six years.
Anyways, I've rambled on enough. You can read more about it here: here and here
And that is how you should develop. But, you should, of course test against real world conditions, once you have working code, and not a moment before. Fix or adjust for the few browser-specific issues that may be left at that point -- they will be far fewer than the issues you create if you code for real world browsers - that's painting yourself into a corner, and pretty much guaranteeing that your product will fail spectacularly when a new browser enters the market.
Which is exactly why you still see web apps that require IE6 and fail for pretty much anything else. They developed for a browser instead of the standard. It's sad that people still try to do this even though history has shown us it's bound to be extremely problematic.
You must be out of the loop: Intel and MeeGo. Hopefully this release will be well received and Intel will continue their work. Also note, all of the tablet developer preview in this release was totally Intel's doing.
What evidence is there that he doesn't "understand the technologies at play here"?
I was referencing this sentence: "Sure, I could TRY to convince the company to switch to a completely different application that is incompatible with skype, just because I want to use Linux" Which is backwards because Skype is the incompatible one, not the other way around.
The "why", which you are keen to discuss and which the GP didn't even allude to, is unimportant.
For anyone who actually cares about open standards, it is important to point out the distinction I made. I just perhaps was a bit too harsh on PARENA at the time.
With respect to PARENA, it does indeed look like he's quite knowledgeable (based on his reply to me), but used a slightly poor word choice IMO.
You misunderstand the technologies at play here. It's not that other clients are incompatible with Skype, it's that Skype decided to turn its nose to the standards already established to effectively lock in users. Obviously it worked. If they were using standard SIP technologies this would be almost no story here.
For every piece of old hardware I have, I can usually find a home for it. I have people asking me for leads on stuff like AT power supplies and boards that aren't all PCI/PCI-E.
I had a hell of a time when I was looking for an 8-bit PCI network card for a 286 machine. Ended up finding one from someone who had bought a bunch of old computers from a government auction. To this day I consider finding one for cheap an extremely lucky occurrence.
I bet Apple is really kicking themselves over the exclusive contract they signed with ATT.
I thought at the time, AT&T was the only one willing to take the iPhone, with all other carriers turning them away. In any case, they still made a killing off the iPhones.
Javascript speed is a strange thing to compete so fiercely on. I don't want to calculate fast fourier transforms in my browser.
Heavy DOM manipulation, and the subsequent redraw is where browsers really hit the wall. Opera seemed to be fastest last time I benchmarked.
One thing that I think has many web developers excited is the possibility of creating browser based games that are on par with that of computer & console games of 10-15 years ago. Take for instance the Quake 2 port to GWT. Because this uses WebGL, it's purely Javascript speed that matters and not DOM manipulation.
You'd probably write it this way then in Go: if( a ) { do_a() } if( b ) { do_b() }
case A: do_a(); break; case B: do_b(); break;
In Go (no real change except it automatically breaks, not sure if I like that yet or not to be totally honest...) case A: do_a() case B: do_b()
if( a ) {
do_a(); }
Again, the first example in Go is what you'd write here again because it forces the use of braces.
I can't stand some language dictating how or where I mark-up my code/comments with extra whitespace or terminators.
To an extent I agree, but I've also seen some people who also believe that and their code not only looks like garbage, and/or there's subtle bugs because they did something like this (in C): if( a )
if( b )
do_something(); else
not_a();// wrong
For example, putting the comma in front, makes it dead easy to extend enums, etc. instead of having to dick around add/removing the last comma.
enum Color { __DUMMY_COLOR
, Red = 0
, Green
, Blue };
I personally don't care for this style. I've also never really heard a compelling argument to make me consider using that style. Back to Go, you're in luck with this example because Go doesn't have a dedicated enum. Instead, you use const. const (
Red = iota
Green
Blue )
Obviously not the most accurate way to do a benchmark, but just throwing this out there:
# Parrot with it's compiled byte-code
fib(28) = 317811 1.11825299263s
parrot -c fib.pbc 1.12s user 0.01s system 99% cpu 1.130 total
# Parrot
fib(28) = 317811 1.1524600982666s
parrot fib.pir 1.15s user 0.01s system 99% cpu 1.165 total
# Mono C#
fib(28) = 317811
Elapsed: 00:00:00.0094437
mono fib.exe 0.02s user 0.01s system 98% cpu 0.030 total
# Python 2.7
fib(28) = 317811
python2 fib.py 0.36s user 0.02s system 99% cpu 0.379 total
# Ruby 1.9.2p0
fib(28) = 317811
ruby fib.rb 0.13s user 0.00s system 97% cpu 0.136 total
# Perl 5.12.1
fib(28) = 317811
perl fib.pl 0.56s user 0.01s system 99% cpu 0.572 total
In Parrot's defense, they have been putting more work lately into optimizations (ever since Rakudo started to become moderately popular and performance issues came up.) Also keep in mind that parrot hasn't really been at a "stable" version for nearly as long as any of the others this "benchmark" was against. Also, IIRC, the philosophy behind Parrot tends to be, "write the code correctly, then optimize, for its easier to optimize code that's correct to begin with then to try to optimize code that's already broken." Or at least something to that effect.
Anyways, I find Parrot to be an interesting project, that I seriously hope can continue improving so the FOSS community can have a good, general purpose VM to work with (Sure the Mono CLI should be safe since it's an implementation of an open standard, but Parrot doesn't have to worry about even that since it's an original implementation.)
Maybe worse than ever because it's not just the API they control, but the language.
Sure, they control the language, but it's typically not the language (or even a few of the standard libraries) that is of concern since it's an open specification. Where the, "we might have cause for concern" comes in is all the libraries/API that Mono implements that is not part of the standard (the.NET framework for instance.) IANAL, but I think they'd have a hard time with any lawsuit against Mono C#, the VM, and the few open spec libraries. On the other hand, I could see it something coming about for the use of their API.NET. Though, IIRC, I think it might be another hard case since Microsoft has repeatedly given Mono developers direct consultation on various aspects of.NET.
1) The games themselves will more or less not care about Cocoa because they'll use the least that they can to get an OpenGL window open and usable.
2) Non-issue, if it's closed source and the person who buys it complains about the driver being closed but the game not, there are bigger issues that person needs to work on. The 100% FOSS users obviously aren't going to want either. So again, they're not going to complain that a closed source game needs a closed source driver to work. As for the closed drivers themselves, AMD/ATI are descent (if you have hardware that they support) & nVIdia's Linux drivers are quite good. The OpenGL renderer for the games will likely need little to no changes to run on these drivers.
One of the big misconceptions by GPL people is they think that if the license is GPL, the potential contributor will be "forced" to contribute back. No, he won't. Anyone that does not wish to contribute will not, regardless of license. He'll either use GPL code, but not distribute, use another project, or roll his own. The GPL did not force anyone to contribute in those cases.
That's just how things go. The not distributing and rolling their own can be hard in situations such as compilers or development tools. Using a different project is always an option, but the same is true in the commercial world. It's the same as choosing a library to use based on the license price, features, whatever. You're going to choose what works best for the project. If not contributing back and keeping the source closed is a deal breaker for the project, GPL isn't going to be an option if you have to release/distribute the program. So you're right, yet, there are still plenty of companies that try to use GPL code without releasing the source till legal action is finally threatened.
By the way, GPL folks, stop being offended for BSD projects when some commercial entity uses their code. It's allowed in the license and the BSD people aren't stupid. They are okay with the use of the code so you should be too. Stop using the Microsoft TCP/IP example. Nobody cared
It's typically not used as an example of them doing anything legally wrong, just more ethically (in their eyes.) GPL advocates at least want the option of being able to incorporate the changes back into the main line, or being able to make further changes to the code that was forked. Someone in another thread said it quite well: BSD gives more freedom to the developers, and GPL gives more freedom to the users. And you're right, the BSD devs didn't/don't care if their code is used commercially without releasing their changes. It's a non-issue to them because they're developers and care more about making developers' lives easier.
Slashdot Mirror
I tend to agree, the potential issue is power consumption (which tends to be higher with x86/x86_64.) My old AMD K5 with 32 Mb RAM, two ethernet cards and a wireless card served me for many years. It was running a minimal Debian with iptables & ssh. I never measured power consumption, but I'd wager it was higher than an off the shelf router.
That's how I switched from Arch to Debian on my work machine. Debootstrap works very well (and I had been using it for chroots for quite some time.)
Will you please provide a link to the $1.95 developer board? I'm only finding PIC chips for that price and not a full boards like the Launchpads & Arduinos.
If you're up to 2GB you're likely seeing a leaky plugin. Firebug, for me, seems to leak. In short, if you're seeing consistent ram usage > 500MB, you should try with all plugins disabled or in safe mode.
I'm at just over 59 hours, and it's at about 400MB* on a 64 bit Arch Linux desktop. That goes out the window when Firebug is on. It seems to leaks memory like crazy. It can easily climb over 1.5GB* in only a few hours of debugging/development.
*Rough estimates based on top
What's with all the strange names?
Let me help you with that
But if I'm using Bash, I obviously prefer a terminal anyways, and have no use for those fancy DE's. Obligatory "Now get off my lawn"
Well, if "MS doesn't make .NET for (his) platform", Visual Studio is totally out of the question. He's most likely on a *nix; so, he'd most likely go with something like MonoDevelop (GTK#) for an IDE and one of these may be chosen for a GUI toolkit (when he eventually gets to that): http://www.mono-project.com/Gui_Toolkits
If he wants to stick with Pascal, he could also consider Oxygene which also runs on top of the CLR/Mono. This has the advantage of using all the classes already available in Mono, but with a similar syntax.
That's a joke right ?
I like the fuzebox project. But that's a 8-bit console. That is never gonna sel massively.
But I guess you were talking about community driven hardware and gaming system. I am still not sure these guys will leave well as well. Why haven't we seen a linux ARM-based or x86 based open gaming system appear ? That's basically, buy a computer and 2 USB gamepad and plug them on your TV. the software is mainly written in the GeeXbox. Still no one knows about it ?
Perhaps he doesn't understand what a niche market is. As for a Linux based gaming system, there are things like The Evo 2 from Envision: http://www.linuxfordevices.com/c/a/News/Envizions-Evo-2/?kc=rss
I'm not going to say it's a realistic alternative to the current generation consoles, because it's most likely going to appeal to a similar niche market as the Uzebox (Note, the Fuzebox is a specific implementation of the Uzebox.)
*shrugs* I may not like it, but that's just how things are currently.
The part of the review I found to be quite funny was this line:
I guess the reviewer never tried IceWM before since it's looked pretty much exactly the same for about 10 years now.
I think the fact that Andrew Tanenbaum riduculed Linux in 1993 for being an "outdated architecture", when Minix just got paging working last year after 20 years of development, encapsulates my point completely.
MINIX 1 & 2 were teaching tools. MINIX 3, which is "loosely based somewhat on previous versions of MINIX," wants to not only be a teaching tool, but also be a serious option for small & embedded systems. Also, this new version of MINIX has only been in active development for about six years.
Anyways, I've rambled on enough. You can read more about it here: here and here
BSD userland on top of GNU Hurd.
"What the hell do you call an OS like that?"
"I'll call it 'The Aristocrats'"
YES!
And that is how you should develop. But, you should, of course test against real world conditions, once you have working code, and not a moment before.
Fix or adjust for the few browser-specific issues that may be left at that point -- they will be far fewer than the issues you create if you code for real world browsers - that's painting yourself into a corner, and pretty much guaranteeing that your product will fail spectacularly when a new browser enters the market.
Which is exactly why you still see web apps that require IE6 and fail for pretty much anything else. They developed for a browser instead of the standard. It's sad that people still try to do this even though history has shown us it's bound to be extremely problematic.
You must be out of the loop: Intel and MeeGo. Hopefully this release will be well received and Intel will continue their work. Also note, all of the tablet developer preview in this release was totally Intel's doing.
What evidence is there that he doesn't "understand the technologies at play here"?
I was referencing this sentence: "Sure, I could TRY to convince the company to switch to a completely different application that is incompatible with skype, just because I want to use Linux" Which is backwards because Skype is the incompatible one, not the other way around.
The "why", which you are keen to discuss and which the GP didn't even allude to, is unimportant.
For anyone who actually cares about open standards, it is important to point out the distinction I made. I just perhaps was a bit too harsh on PARENA at the time.
With respect to PARENA, it does indeed look like he's quite knowledgeable (based on his reply to me), but used a slightly poor word choice IMO.
You misunderstand the technologies at play here. It's not that other clients are incompatible with Skype, it's that Skype decided to turn its nose to the standards already established to effectively lock in users. Obviously it worked. If they were using standard SIP technologies this would be almost no story here.
For every piece of old hardware I have, I can usually find a home for it. I have people asking me for leads on stuff like AT power supplies and boards that aren't all PCI/PCI-E.
I had a hell of a time when I was looking for an 8-bit PCI network card for a 286 machine. Ended up finding one from someone who had bought a bunch of old computers from a government auction. To this day I consider finding one for cheap an extremely lucky occurrence.
I bet Apple is really kicking themselves over the exclusive contract they signed with ATT.
I thought at the time, AT&T was the only one willing to take the iPhone, with all other carriers turning them away. In any case, they still made a killing off the iPhones.
Javascript speed is a strange thing to compete so fiercely on. I don't want to calculate fast fourier transforms in my browser.
Heavy DOM manipulation, and the subsequent redraw is where browsers really hit the wall. Opera seemed to be fastest last time I benchmarked.
One thing that I think has many web developers excited is the possibility of creating browser based games that are on par with that of computer & console games of 10-15 years ago. Take for instance the Quake 2 port to GWT. Because this uses WebGL, it's purely Javascript speed that matters and not DOM manipulation.
And in the not too distant future, some DRM inside you will disable your movements so you have to watch the ads
if( a )
do_a();
Well, in Go you'd have to do:
if( a ) {
do_a()
}
if( a ) do_a();
if( b ) do_b();
You'd probably write it this way then in Go:
if( a ) { do_a() }
if( b ) { do_b() }
case A: do_a(); break;
case B: do_b(); break;
In Go (no real change except it automatically breaks, not sure if I like that yet or not to be totally honest...)
case A: do_a()
case B: do_b()
if( a )
{
do_a();
}
Again, the first example in Go is what you'd write here again because it forces the use of braces.
I can't stand some language dictating how or where I mark-up my code/comments with extra whitespace or terminators.
To an extent I agree, but I've also seen some people who also believe that and their code not only looks like garbage, and/or there's subtle bugs because they did something like this (in C): // wrong
if( a )
if( b )
do_something();
else
not_a();
For example, putting the comma in front, makes it dead easy to extend enums, etc. instead of having to dick around add/removing the last comma.
enum Color { __DUMMY_COLOR
, Red = 0
, Green
, Blue
};
I personally don't care for this style. I've also never really heard a compelling argument to make me consider using that style. Back to Go, you're in luck with this example because Go doesn't have a dedicated enum. Instead, you use const.
const (
Red = iota
Green
Blue
)
Obviously not the most accurate way to do a benchmark, but just throwing this out there:
# Parrot with it's compiled byte-code
fib(28) = 317811 1.11825299263s
parrot -c fib.pbc 1.12s user 0.01s system 99% cpu 1.130 total
# Parrot
fib(28) = 317811 1.1524600982666s
parrot fib.pir 1.15s user 0.01s system 99% cpu 1.165 total
# Mono C#
fib(28) = 317811 Elapsed: 00:00:00.0094437
mono fib.exe 0.02s user 0.01s system 98% cpu 0.030 total
# Python 2.7
fib(28) = 317811
python2 fib.py 0.36s user 0.02s system 99% cpu 0.379 total
# Ruby 1.9.2p0
fib(28) = 317811
ruby fib.rb 0.13s user 0.00s system 97% cpu 0.136 total
# Perl 5.12.1 fib(28) = 317811
perl fib.pl 0.56s user 0.01s system 99% cpu 0.572 total
In Parrot's defense, they have been putting more work lately into optimizations (ever since Rakudo started to become moderately popular and performance issues came up.) Also keep in mind that parrot hasn't really been at a "stable" version for nearly as long as any of the others this "benchmark" was against. Also, IIRC, the philosophy behind Parrot tends to be, "write the code correctly, then optimize, for its easier to optimize code that's correct to begin with then to try to optimize code that's already broken." Or at least something to that effect.
Anyways, I find Parrot to be an interesting project, that I seriously hope can continue improving so the FOSS community can have a good, general purpose VM to work with (Sure the Mono CLI should be safe since it's an implementation of an open standard, but Parrot doesn't have to worry about even that since it's an original implementation.)
Maybe worse than ever because it's not just the API they control, but the language.
Sure, they control the language, but it's typically not the language (or even a few of the standard libraries) that is of concern since it's an open specification. Where the, "we might have cause for concern" comes in is all the libraries/API that Mono implements that is not part of the standard (the .NET framework for instance.) IANAL, but I think they'd have a hard time with any lawsuit against Mono C#, the VM, and the few open spec libraries. On the other hand, I could see it something coming about for the use of their API .NET. Though, IIRC, I think it might be another hard case since Microsoft has repeatedly given Mono developers direct consultation on various aspects of .NET.
Anyways, just thoughts on the issue. See also: http://www.mono-project.com/ECMA
1) The games themselves will more or less not care about Cocoa because they'll use the least that they can to get an OpenGL window open and usable.
2) Non-issue, if it's closed source and the person who buys it complains about the driver being closed but the game not, there are bigger issues that person needs to work on. The 100% FOSS users obviously aren't going to want either. So again, they're not going to complain that a closed source game needs a closed source driver to work. As for the closed drivers themselves, AMD/ATI are descent (if you have hardware that they support) & nVIdia's Linux drivers are quite good. The OpenGL renderer for the games will likely need little to no changes to run on these drivers.
3) Short answer: yes http://www.wolfire.com/humble http://2dboy.com/2009/10/26/pay-what-you-want-birthday-sale-wrap-up/ Long answer: more than likely. The most common complaint I've heard over the years from Linux users is the lack of commercial/popular games that are only available on Windows (or Windows and OS X)
One of the big misconceptions by GPL people is they think that if the license is GPL, the potential contributor will be "forced" to contribute back. No, he won't. Anyone that does not wish to contribute will not, regardless of license. He'll either use GPL code, but not distribute, use another project, or roll his own. The GPL did not force anyone to contribute in those cases.
That's just how things go. The not distributing and rolling their own can be hard in situations such as compilers or development tools. Using a different project is always an option, but the same is true in the commercial world. It's the same as choosing a library to use based on the license price, features, whatever. You're going to choose what works best for the project. If not contributing back and keeping the source closed is a deal breaker for the project, GPL isn't going to be an option if you have to release/distribute the program. So you're right, yet, there are still plenty of companies that try to use GPL code without releasing the source till legal action is finally threatened.
By the way, GPL folks, stop being offended for BSD projects when some commercial entity uses their code. It's allowed in the license and the BSD people aren't stupid. They are okay with the use of the code so you should be too. Stop using the Microsoft TCP/IP example. Nobody cared
It's typically not used as an example of them doing anything legally wrong, just more ethically (in their eyes.) GPL advocates at least want the option of being able to incorporate the changes back into the main line, or being able to make further changes to the code that was forked. Someone in another thread said it quite well: BSD gives more freedom to the developers, and GPL gives more freedom to the users. And you're right, the BSD devs didn't/don't care if their code is used commercially without releasing their changes. It's a non-issue to them because they're developers and care more about making developers' lives easier.