32mb vram pretty much rules it out for most games.
hell it pretty much rules it out for all but the most basic video editing.
it's quite sufficient for irc and email though:-P
not to mention the mini's vga output is busted. the signal is out of spec, the voltage is too low by roughly 30% due to an engineering error by apple. very annoying. this means whites turn out as off grey.
90% of the additional software that comes with osx (ilife, bleah) is forgettable junk. there are free (or dead cheap) equivalents on linux and win32 for most of that stuff. ilife is hardly a killer app to make macs fly off the shelf. the only app even remotely interesting is idvd, and apple's mpeg encoder isnt particularly good.
for roughly the same amount of money you can get a much faster and all round more powerful pc _with keyboard and LCD monitor_.
apple didn't innovate with the mac mini. they just copied what pc vendors have been doing for years with x86 PCs. (cappucino pc for example). there are even more powerful x86 PCs that are even smaller than the mini.
so its not intel that's playing knock-off -- it's apple.
on the other hand, apple is not innovating the micro pc market via the mac mini. apple is following the lead of what's already been done for many years in the x86 market. (cappucino pc for example, and there are hundreds of others.)
the most notable thing about the mini is that it's a cheap mac. the small size is a side effect of all the corner cutting to make a mac that cheap.
this has nothing to do with java not being 'free'.
nobody uses java (not just the linux crowd) because java is broken -- sun ensures it stays that way. java bytecode portability is a myth -- too much shit breaks on the different VMs.
even if you do that you still need to #ifdef out architecture specific code blocks -- unless you break them up into separate source and object files (but this then complicates your build system).
you also back yourself into the corner of having to keep all the different source files of each separate architecture coherent. which brings us full circle back to the original point i made about that being a very bad idea.
so no, rewriting ifdefs into functions is generally worse.
unless of course you are thinking of macros, which is sometimes even worse and opens up a whole new can of worms (compiler bugs, optimization issues, etc.)
it has a lot of ugly nextstep-isms though, including the heavy leanings toward objc and bundles.
and for a long time osx was missing even basic freebsd mechanisms like dlopen() (yes, i know someone wrote a wrapper, but it took a long time for apple to appropriate it as an official api).
just FYI. mingw doesn't deal with api differences at all. mingw is just a gcc port which can emit win32 PE binaries. a good deal of mingw effort is spent writing free versions of win32 dlls to link against. but they don't abstract or translate APIs -- they're just free implementations of the win32 SDK.
cygwin does deal with api differences however. it's a completely different beast.
#ifdefs are a tool like any other. use them when they make sense, when they are the best tool for the job. they are not always the best tool, but "never" (as you imply) is the wrong answer also.
writing 5 different copies of the same function is often more counterproductive than one with 5 little #ifdefs in it.
moving code out into separate modules can introduce other problems such as increased effort to keep all the individual architecures coherent -- which increases the risk of bugs creeping in. this approach is often counterproductive.
Porting to other platforms/architectures often reveals bugs in your primary target platform. it is often worth the effort to port to other platforms on this basis alone.
also, if it takes you a lot of effort to keep architecture-nimble, there is something fundamentally wrong with your design. this in itself should be a warning.
But there is no benefit at all in supporting something like PA Risc, m68k, cris, etc as configurations of the generic code.
ulrich obviously has no clue whatsoever about embedded systems, and should therefore stfu on this point. one of the most popular embedded platforms is a 68k variant (coldfire) -- it's probably second behind ARM. by dumping support of 68k you castrate linux in the embedded marketplace. there's much more to 68k linux than sun3 and atari/amiga.
his rant against mingw as "undeserving" is stupid. mingw is an enabler -- it means people can develop for win32 without having to pay microsoft $$$$ for the privilege of doing so.
his 'dictatorship of the minorities' argument is actually self-defeating on this point because microsoft users are in the majority. by his own arguments, we should be concentrating on supporting win32 as the primary target for gcc and primary architecture for linux.
utterly ridiculous.
bug-eyed rants like his just serve to reinforce the stereotype that all open source advocates are completely unhinged. it is not helpful in the least.
phrack was a social engineering experiment...
on
PHRACK Final
·
· Score: 1
...testing how much BS they could spew before anyone would notice. the very first article is a prime example.
go ahead mr. glickman. take your ball and go home. quite frankly nothing would make me happier.
you can go take your "survivor", "american idol", "desperate housewives", and shove it. i don't give a shit about this inane drivel you try to ram down our throats, and I care even less to see this banality in "hi def".
the sooner you and the industry you represent burns in hell, the better off humanity will be.
So you're responsible for ensuring television broadcasts continue to function?
I have some suggestions.
1) get a job which doesnt require selling your soul to el diablo. (this means a job at microsoft is out too:-) 2) if you can't 1), then commit suicide immediately and make the world a better place.
the faster broadcast TV dies, the better off the world will be.
Cells would be perfect for accelerating eg SSH and SSL -- it should be great for crypto in general. Also things like compression - gzip/bzip2/etc. would benefit.
For desktops Cells should be awesome. But servers should still find some good use for them.
Programmers are creative. I'm sure many great uses will be found to utilize Cells in purely server environments.
So in other words, if I have a grudge against you and I know you encrypt your private data (say, credit cards, financial data, maybe an embarassing adulterous fling or two), I can make a false accusation of child porn against you.
The police don't find anything on your PC, but hey -- you have encryption! That means you must be hiding something incriminating. And oh, you can't provide proof that you're not hiding encrypted child porn, so we're going to assume you are.
Slashdot Mirror
full desktop pc with lcd monitor, keyboard, mouse, dual layer dvd burner, 80gb hd, 512mb ram, 2.66ghz p4, speakers and windows xp for $529.
enjoy.
32mb vram pretty much rules it out for most games.
:-P
hell it pretty much rules it out for all but the most basic video editing.
it's quite sufficient for irc and email though
not to mention the mini's vga output is busted. the signal is out of spec, the voltage is too low by roughly 30% due to an engineering error by apple. very annoying. this means whites turn out as off grey.
90% of the additional software that comes with osx (ilife, bleah) is forgettable junk. there are free (or dead cheap) equivalents on linux and win32 for most of that stuff. ilife is hardly a killer app to make macs fly off the shelf. the only app even remotely interesting is idvd, and apple's mpeg encoder isnt particularly good.
for roughly the same amount of money you can get a much faster and all round more powerful pc _with keyboard and LCD monitor_.
I bought it as a development system for porting OSX apps to, because it was the cheapest mac you could get. could care less about the size.
It's a bit too limiting though. Something in a Shuttle SFF size would have been light years better.
apple didn't innovate with the mac mini. they just copied what pc vendors have been doing for years with x86 PCs. (cappucino pc for example). there are even more powerful x86 PCs that are even smaller than the mini.
so its not intel that's playing knock-off -- it's apple.
on the other hand, apple is not innovating the micro pc market via the mac mini. apple is following the lead of what's already been done for many years in the x86 market. (cappucino pc for example, and there are hundreds of others.)
the most notable thing about the mini is that it's a cheap mac. the small size is a side effect of all the corner cutting to make a mac that cheap.
i'm happy with my shuttle sb52g2. very solidly constructed and great expandability.
they aren't apple's chips. they're IBM's.
the mini also has no audio input.
what's top stop them from using integrated nvidia? that's light years faster than the POS ati 9600 in the mini.
and i _have_ a mini. this thing is _not_ fast.
why does it have to be $249 out the door? the mini's lowest end is $499.
they could easily do a $499 x86 mini pc with all the trimmings _and_ a copy of windows xp. hell you can get a full desktop pc with lcd monitor, keyboard, mouse, dual layer dvd burner, 80gb hd, 512mb ram, 2.66ghz p4, speakers and windows xp for $529.
it's not much of a stretch to say a wintel pc could easily be competetive on every hardware point.
typical laptop is a 2ghz p4 or amd64 these days. with nvidia or ati integrated video. a lot better than the pitiful 32mb ati 9600 in the mini.
and i have a mini. just about any x86 laptop is faster than this thing.
it is most definitely not fast compared to a laptop or desktop. it's not even competetive with shuttle SFF's and its much less expandable.
it's a cheap mac, that's its main call to fame. period. the small size is just a side effect of all the cost cutting to get it that cheap.
this has nothing to do with java not being 'free'.
nobody uses java (not just the linux crowd) because java is broken -- sun ensures it stays that way. java bytecode portability is a myth -- too much shit breaks on the different VMs.
Insightful my ass. Mods on crack again.
the movement from glibc2.2 to 2.3 was particularly painful. ugh.
I wouldn't worry about it. Just about everybody on the entire planet agrees Uli is completely and utterly wrong on every single point.
er, sorry. no.
even if you do that you still need to #ifdef out architecture specific code blocks -- unless you break them up into separate source and object files (but this then complicates your build system).
you also back yourself into the corner of having to keep all the different source files of each separate architecture coherent. which brings us full circle back to the original point i made about that being a very bad idea.
so no, rewriting ifdefs into functions is generally worse.
unless of course you are thinking of macros, which is sometimes even worse and opens up a whole new can of worms (compiler bugs, optimization issues, etc.)
expose is needed because the osx window manager sucks donkey dick.
GUIs with decent window managers don't need expose.
oh, and the apple dock sucks horribly too. the original nextstep dock was a jillion times more functional -- jobs really fucked up with the osx dock.
and boy is it ever ugly.
it has a lot of ugly nextstep-isms though, including the heavy leanings toward objc and bundles.
and for a long time osx was missing even basic freebsd mechanisms like dlopen() (yes, i know someone wrote a wrapper, but it took a long time for apple to appropriate it as an official api).
just FYI. mingw doesn't deal with api differences at all. mingw is just a gcc port which can emit win32 PE binaries. a good deal of mingw effort is spent writing free versions of win32 dlls to link against. but they don't abstract or translate APIs -- they're just free implementations of the win32 SDK.
cygwin does deal with api differences however. it's a completely different beast.
#ifdefs are a tool like any other. use them when they make sense, when they are the best tool for the job. they are not always the best tool, but "never" (as you imply) is the wrong answer also.
writing 5 different copies of the same function is often more counterproductive than one with 5 little #ifdefs in it.
moving code out into separate modules can introduce other problems such as increased effort to keep all the individual architecures coherent -- which increases the risk of bugs creeping in. this approach is often counterproductive.
Porting to other platforms/architectures often reveals bugs in your primary target platform. it is often worth the effort to port to other platforms on this basis alone.
also, if it takes you a lot of effort to keep architecture-nimble, there is something fundamentally wrong with your design. this in itself should be a warning.
But there is no benefit at all in supporting something like PA Risc, m68k, cris, etc as configurations of the generic code.
ulrich obviously has no clue whatsoever about embedded systems, and should therefore stfu on this point. one of the most popular embedded platforms is a 68k variant (coldfire) -- it's probably second behind ARM. by dumping support of 68k you castrate linux in the embedded marketplace. there's much more to 68k linux than sun3 and atari/amiga.
his rant against mingw as "undeserving" is stupid. mingw is an enabler -- it means people can develop for win32 without having to pay microsoft $$$$ for the privilege of doing so.
his 'dictatorship of the minorities' argument is actually self-defeating on this point because microsoft users are in the majority. by his own arguments, we should be concentrating on supporting win32 as the primary target for gcc and primary architecture for linux.
utterly ridiculous.
bug-eyed rants like his just serve to reinforce the stereotype that all open source advocates are completely unhinged. it is not helpful in the least.
...testing how much BS they could spew before anyone would notice. the very first article is a prime example.
Just to clarify things, when the atari st/amiga were released, there was no MS monopoly. It was IBM who was the monopolist.
broadcast TV can FOAD.
go ahead mr. glickman. take your ball and go home. quite frankly nothing would make me happier.
you can go take your "survivor", "american idol", "desperate housewives", and shove it. i don't give a shit about this inane drivel you try to ram down our throats, and I care even less to see this banality in "hi def".
the sooner you and the industry you represent burns in hell, the better off humanity will be.
So you're responsible for ensuring television broadcasts continue to function?
:-)
I have some suggestions.
1) get a job which doesnt require selling your soul to el diablo.
(this means a job at microsoft is out too
2) if you can't 1), then commit suicide immediately and make the world a better place.
the faster broadcast TV dies, the better off the world will be.
Cells would be perfect for accelerating eg SSH and SSL -- it should be great for crypto in general. Also things like compression - gzip/bzip2/etc. would benefit.
For desktops Cells should be awesome. But servers should still find some good use for them.
Programmers are creative. I'm sure many great uses will be found to utilize Cells in purely server environments.
You can bet he'll get sued.
bittorrent provides an excellent distribution mechanism for opensource projects (linux,bsd,openoffice,mozilla,etc).
opensource is a major threat to the BSA's members, and the BSA is diametrically opposed to opensource.
The BSA will attack bittorrent with the rallying cry of "anti piracy" but a secondary goal is to hurt opensource.
So in other words, if I have a grudge against you and I know you encrypt your private data (say, credit cards, financial data, maybe an embarassing adulterous fling or two), I can make a false accusation of child porn against you.
The police don't find anything on your PC, but hey -- you have encryption! That means you must be hiding something incriminating. And oh, you can't provide proof that you're not hiding encrypted child porn, so we're going to assume you are.
Sounds very convenient to me.