I've been using Flash for a while now, and there's quite a few things I like about it.
Its programming language has evolved to something pretty nice these days. I find it a lot easier to seperate the frontend and the backend using flash than using html. (html/php mixes too much code and look, and PHP->XML->XSLT->HTML is ridiculous, and buys you very little. The only thing that kindof works is relatively simple templates)
The only thing I don't like about it, is that it doesn't "gracefully degrade", I mean it's still too hard to expose the structure/content/flow like you can with html.
On the other hand, if I try to do everything by the book using standard xhtml/css/js, for the more complicated things I spend ages getting things to look/react right in the different browsers I want to support (IE Mac&Windows>5, Mozilla,...)
The fact that Flash is completely vector based is also a major asset, now that there's such a wide range of resolutions in use. (everything between 800x600 and 1600x1200 is extremely common - if I create fixed-pixel content for 800x600 I can guarantee you it'll look too small in 1600x1200)
If I compare html and flash on features and general usability, I'd score both almost evenly: they both have things going for them. As long as I need to create simple information based sites, I use html. The minute I need to make something more complicated like a "web app" I use Flash.
I would define myself as an advanced user, and am using win2k and linux on a daily basis. Because I'm almost running Linux full time, I haven't really felt the need to upgrade to XP, which probably accounts for my unfamilliarity with the new "Luna" UI.
But seeing this almost makes me want to puke. Even though I've been using computers for decades, I wouldn't know where to begin in this UI. There seems to be redundancy all over the place, modes galore, and they seem to show/hide certain tasks/apps/files/settings/menu options completely at random.
I have to admit, maybe if I used it I would like it a bit better. But if I feel "overwhelmed" just by looking at one of the screenshots, how should a newbie user feel. (I seem to remember that when doing usability testing, they ask the subject to first look at the screen without touching anything, and then ask them what they think everything is for)
In contrast, Gnome2 seems to be moving in the right direction by simplifying ("make the simple things easy, the hard ones possible") and unifying as much as possible.
Same thing with MacOS: while the first releases of MacOSX were a step back in usability, they've been repairing the damage with the latest release. At the same time it's a good example of how unification really should work (see the iChat, iSync, iCal, Addressbook, Mail, iTunes integration)
Longhorn and XP seem to like confusion: let's do everything in all the ways everyone in the world might want, and stuff it in one interface. And let's do it all at thesame time too.
This is the Free Standards Group (FSG), not the Free Software Foundation (FSF).
This is about standardizing things across distributions, and setting up a set of useful guidelines that have been well thought through.
Some things I think need researching:
- A bunch of wrappers aimed at making it easy to write GUIs for services (activation, status, description), hardware/network/... configuration, etc etc. A bit like standardizing the backends of the ex-Ximian Setup Tools. - A decent set of guidelines to handle virtual hosts on servers + wrappers for their configuration/administration. - moving beyond the fhs: new filesystems and kernel changes introduced will allow a whole bunch of new functionality. I'd like to see some discussion starting about how we can leverage the advantages of union mounts ( "/" vs "/usr": really still needed?), extended attributes and ACL's, LVM etc.
I'd also very much like a comparison with completely different filesystem layouts like MacOSX. I realize that the FHS came to be for very good reasons, but I'm hoping that since we'll have all these features available to us we'll be able to simplify the structure alot without giving up any of the advantages. It's not always nice to be stuck in a lowest common deminator legacy world.
Capacity increases very quickly. That's nice. But what I really care about is performance keeping pace.
I mean, the actual transfer rate with which one can get (ever more) data on or off the disks is increasing very slowly.
The ratio of speed vs capacity is getting worse and worse.
I'd much prefer less capacity and much better performance. Yes, I know I could go RAID0, but that means twice the noise, power consumption, and risk to reliability. Maybe they should have something like raid0-in-a-drive?
Well, you got scammed - you didn't need to go back to VGA. if you got a DVI-I plug and a DVI-D plug, You can use a DVI-I or DVI-D to connect the two digitally.
Check out this passage from a DVI faq: "
If you have plugs that are DVI-D, they will accept a DVI-D or DVI-I cable. If you have plugs that are DVI-A, they will accept a DVI-A or DVI-I cable. If you have plugs that are DVI-I, they will accept any type of DVI cable.
If you have mistmatched plugs, such as DVI-D and DVI-I or DVI-A and DVI-I, you may use either a DVI-I cable or the cable that matches the other plug. For example, you may use a DVI-D cable on a DVI-I to DVI-D connection, but not a DVI-A cable.
Note: You may not mismatch a DVI-D and a DVI-A connection. "
As I understand it, with the current system patent examiners have the task to find out whether or not a patent application is truly new/innovative/...
This implies that if you take the path of least resistance (underfunded patent examiners/time constraints/whatever/...) by default, the patent will pass, and a monopoly on the device (albeit temporary) is given out. Effort has to be made to stop a patent application.
Isn't this placing the "burden of proof" at the wrong side? Shouldn't it be so, that by default the patent should NOT be given out?
I've heard (don't know if this is correct) that with the USPTO the patent examiners get rewarded for every patent granted. Shouldn't the patent examiners get a reward for every patent application blocked?
wasn't there a slashdot story at one point where content providers in Norway (not sure) wanted to band together and demand a percentage of what ISP made, because "they were the reason people got on the internet".
Now it's the other way around - "we provide you with customers, so give us some money"
I've been pondering about maybe replacing the DNS system outright.
Something that is distributed, and based on a kind of certification that the users give. Something that would of course have to be attack-resistent (in the sense that a single entity or small group can't profoundly influence the certification of a name->ip mapping on it's own)
The major problem I see, aside from the obvious difficulties in implementing and deploying such a system, is in organising the namespace. Can a name be owned by more than one entity?
You could imagine a system where names would have a subjective meaning, depending on what you and your 'friends' have certified. Other people could get a different entity for the same name.
Needless to say this subjective view is more than just annoying if you think about email for instance. You don't know if a name will lead you to a specific entity. All you're sure of is that the people you trust have picked this one.
Enforcing the one name-one entity mapping could however lead to problems like we currently have: - first come, first served is a good rule, but gives opportunities to cybersquatters. Conflicting trademarks need to be worked out. Big corp with a trademark practically always wins over an well-intentioned individual. Inevitably disputes follow, courts get involved, lawmakers get involved, everything gets messy and too expensive for individuals, so individuals drop out. - we could have a global certification where the majority of votes wins. But that leaves little protection for unpopular entities (ie tyranny of the majority).
I'm using vtun.sourceforge.net (which is still under active development) combined with the universal tun/tap driver in the kernel and the linux bridging code to create a more generic solution.
On both sides I create bridges which enslave a physical nic, and the "virtual" tap device.
Since this is an ethernet, not an IP tunnel, it tunnels appletalk, and should tunnel IPX and other traffic too.
It can be compressed and (of course) encrypted too. Performance is very good, even for multiple tunnel, and can be tweaked according to the processor power available.
This way I have even bridged more than two geographical locations too. For instance with 3 connections 1,2,3 I had connections between 1-2, 2-3 and 3-1. But because of the bridging code Spanning Tree Protocol, those redundant connections will only buy you "backup" connections, there's still going to be two nodes that have to communicate via a third. (If you use vtun to do IP tunneling instead of ethernet tunneling, you can use proper routing of course.)
I'm very happy with vtun, it's easy and extremely versatile.
- I set up a personal imap server. Fetchmail is also running on that box. - I use evolution to sync my calendar/contacts/etc - I can use both evo and mozmail to check out my imap mailbox - I use programs like mailsync to synchronize my palm straight with the imap server.
"Blame the companies who tell the programmers what to do"
Bah. Since you're working for the company, you _are_ in effect part of the company, and share some responsability for its actions.
I wish people would try to be more consistent in their behaviour, and put their money where their mouth is. There's loads of jobs out there especially in the IT sector, even in these post-dot-com times, and I'm sure some of them don't conflict with your personal sense of ethics. Yes, they might pay a little bit less.
A soldier killing someone shares at least a part of the responsability with the chain of command that ordered the killing. People seem to find it easy to hide behind duty/a nation (just look at what happened in WWII), or more appropriate for these times, behind their company.
An oath like this is supposed to work a bit like a union - it forces everyone to be ethical, and would make sure "evil" companies can only find ethical coders (damn!). The fact that this isn't practical IRL doesn't mean you should just be unethical.
Ethical behaviour is doing the right thing, even if it does NOT yield thesame financial benefits/power/geek toys/whatever/... If you're just "ethical" when it's convenient, well...
It seems it's quite popular to say Flash is eeeeviiil, but I'd like to make a case for it:
- You can make a site that's very small, and still looks good (80kb) - You're sure of how it will look at the user's side. Fonts for instance are embedded in the format. - The format is as open as for instance pdf (check www.openswf.org) and there's lots of open source libraries and tools that use it. - You can make it so it's scalable - so it adapts to the size of your browser window. This is important to me, because I can't count the number of times I cursed when I'm viewin html websites on my high-res monitor because they used fixed font-sizes in their css.
Yes, it's true that there's alot of crap sites out there made in Flash. I get the willies everytime I see an "intro". But there certainly also are a lot of crap HTML sites.
Using jpegs or gifs that are 100kb to begin with, or that just cram so much text in a view that you don't know where to start looking, and you get a headache to begin with.
At least with Flash you don't have to deal with slight differences in rendering CSS boxes between internet explorer 5.0 and 5.0 SP2 or whatever. (Even mozilla has it's share of anomalies)
Even if you do your entire html site "by the book" , spec-compliant, clean, etc, you can't avoid encountering bugs between the different implementations.
The only reason _NOT_ to use flash, is because there's no adequate Flash editor for Linux, (or for that matter, an adequare vector drawing program for linux either) - it's the only reason I still need to dual-boot. I'll try wine+flash soon - hoping it's usable.
What makes a good website? Well, it all depends on the actual information you have to offer. If people can find something interesting on your site, and the UI of your site doesn't get in the way, or even, does actually _help_ the visitor to find what they're looking for, then you succeeded.
IIRC, there is a way to sign packages, and there's also a way to do all the questions up front with debconf (apt-utils? not sure) - debconf also has a noninteractive mode, but i don't know if that's any good, never tried it.
You're right about the logging. I disagree about the previous versions of packages, i sometimes have four previous packages in apt's cache. Do you apt-get clean every time you upgrade?
Actually, compression has artifacts, but they're different than "line noise". So yes, the quality will be even lower, and if you can hear the line noise in the uncompressed recording, you'll probably will also hear it in the mp3/ogg.
Some other poster mentioned a flash connected to your ide. But if you're adventurous, you can use something like the linuxbios project (http://linuxbios.org) - what they are doing is overwriting your bios using a stripped down version of linux. Then it can boot another linux image from disk, or from the network.
Additional advantage: you get in linux in 3 seconds in some cases:)
Of course it all depends if your chipset supports it, and if you're willing to risk it. (of course if you have a flasher, so that you can restore a working bios image it's less of a risk)
I find the prices for these things a bit too steep. So i set out to make one, but i hit the problem when i tried finding these components in local electronics shops.
anyway here's an address:
http://rcswww.urz.tu-dresden.de/~sb831436/irda/i rd a.htm
concurrent connection problems? isn't that what JID's are for? Of course you shouldn't all leave them on "JabberIM" or something - the point is that they should be unique
i agree on the keystroke issue in JIM - didn't realise your issue with MSN.
I'd say one of the things that's keeping Berlin back is the boatloads of misinformation that's going around.
First off - berlin isn't _tied_ to Python; Stefan just suggested using it as a simple prototyping tool - Berlin is language independent (everything happens thru Corba) In fact, the server part is mostly written in C++, but there's client apps in lots of languages.
And no; Berlin isn't just another widget set like some other poster suggested. It allows flexibility (so you won't lose your precious "choice"); but if you "theme" something, it happens on the server; _that's_ where policy is defined - in one central place, like it should be (don't get me started on what a bad idea "meta-theming" is - that just suggests a bad design i believe)...
Apps shouldn't have to bother with the gui, let it be done on the side where it's best done (the display server is closest to the hardware - so the work should be done there) Oh; and by the way: it _has_ anti-aliasing, and way more to boot (it's vector based)
Everyone's always moaning about whether or not innovation is possible with free software/open source; This is an excellent example of great innovation in my mind...
The sad thing is no-one seems to understand or care.
Having this extra layer, allows them to adopt a radically different hardware-architecture for their next-gen product, without having to worry about breaking compatibility, since that layer takes care of that.
You can try to do that in hardware, but you'd end up with the systems amd and intel are using (breaking x86 ops up in smaller ones), and that costs you a significant amount of die space.
I suppose it would be possible to make something native for the crusoe. Problem is it would probably be compatible with this version only!
Don't focus on the situation as it is now. Try to look at it as a "process", an evolution.
I think with the setup they currently have, they'll be able to design new chips that remain x86 compatible and make improvement, at a faster rate than their competition. The people that design the software can ask the hardware guys for specific features that would make emulation faster, and the software guys can make very specific optimizations to that specific fixed hardware - they don't have to worry about the common-denominator problem (what happens with the speed on amd's if i optimize for intel and vice-versa)
I think it definately has a future. Some people might think they're off to a slow start (i'm definately not one of these people - having an emulator perform this good is not an easy feat i believe) but i think they will have the possibility to include improvements and innovations faster than the traditional chipmakers. (unlike for instance intel that has to design a core and live with it for over 5 years).
For instance, a color picker might be almost unnecessary on a palm, and I can't think of better use of a 3d environment than mapping a 2D ui on a texture and displaying it in 3D. As i said it's up to the server (or one of its plugins)
should be "...
for instance, a color picker might be almost unnecessary on a palm, and should be replaced on the server by something simpler, and I CAN think of better use of a 3d environment than mapping a 2D ui on a texture and displaying it in 3D.
First, one should realize that it overlaps with more than just the X server.
Berlin is different in that, unlike X, it doesn't communicate between client-app and the server by pushing pixels around. It's the responsability of the server to create a decent (looking) ui, based on the calls the app makes. The fact that those calls are made using CORBA, means they're network, and language independent (perl anyone?).
Using corba shouldn't be scary, in fact, Berlin is much lighter on bandwith in the case of remote display.
A Berlin app can choose the level of abstraction it needs... Some apps might choose/need to draw low level primitives, while others would want to be able to position widgets themselves, while even others just don't need/want to occupy themselves with how something might look, and just tell the server a specific "task", and let it handle it. If you want to get even higher than that, you should take a look here:
http://www.bucksch.com/1/projects/berlin/OOUI/
Why all these levels? Well, the higher level you go, the more freedom you give the server to implement a certain function in a particular way. For instance, a color picker might be almost unnecessary on a palm, and I can't think of better use of a 3d environment than mapping a 2D ui on a texture and displaying it in 3D. As i said it's up to the server (or one of its plugins)
Portability to totally different platforms doesn't always make sense; for instance, it wouldn't make sense to try to force 3d apps/models/vertices and the like in a palm; So if an app wants to use 3d models, it has to create them using a lower level 3d "kit" (which is just another server plugin). That way, the app writer can choose the trade-off.
Other things that I find important are: the resolution-independence (why are >1600x1200 or 640x480 displays almost unusable without heavy adjustments?); the fact that the policy is defined on the server (am i the only one that thinks "meta-theming" - making theme "packages" for different toolkits that go together - is a kludge)
Where does Gtk+ come in? Right now, Berlin sits on top of lower level graphic libraries (libart+ggi, opengl, others are possible). recently it's been possible to use GGI inside Berlin too... so that makes it: GGI on Berlin, on GGI on FB/X/glide/whatever (btw libGGI 2.0 will be out soon). Knowing this there would be 2 different ways of porting GTK+:
1) port GTK+ to GGI - additional benefits are that you get a whole lot of GGI "targets" gtk+ would work on. From what i hear GDK is pretty easy to port.
2) intercept the gtk widget creation calls and map them to the Berlin widgetkit. Advantage: gtk apps would blend in pretty well with real berlin apps, and have all berlin's advantages of being higher level and pixel independent. Disadvantage: i would think it would be _alot_ harder to do.
I guess the difference between the two is a bit (tiny bit) similar to the difference between Wine (api reimplementation) and running plex86 to run windows itself.
Now if Berlin's so great, why hasn't it taken off yet. Unfortunately, the best doesn't always win. DPS for X isn't there yet (dps.sourceforge.net), despite the fact that it's "proven to be good" by for instance MacOSX. (okay it's not entirely thesame but you get my drift)
A major problem with Berlin is that to explain the advantages, you have to write as much as i did just now. Once you know the advantages, it seems obvious that this is the way to go, but as i said, even the people who are interested don't always understand the advantages about it immediately. That means that few developers actually get into it, meaning slow progress and no critical mass yet.
Otoh, the fact that it has gone on for all these years, even when new good-looking ui tech came out, and that the developers still aren't giving up on it at all, proves that a) they're fools or b) they're onto something.
I definately don't think these people are fools. I believe it's one of the few OSS projects that is actually really innovating.
It's not like specific configuration programs will be magically able to work on all configuration files because they are in XML. It doesn't make a lot of difference.
Second point: it doesn't have much to do with the kernel. how many things in etc are really linked to the kernel? and for procfs? Ideally we would have just a elaborate directory structure where each file just has _one value_, and not a whole text to parse. No use putting xml there or you'll get trees (xml) within files in trees (directories), kinda beats the point.
If you like the idea of unifying things that much, look into Gconf and the like.
Slashdot Mirror
I've been using Flash for a while now, and there's quite a few things I like about it.
...)
Its programming language has evolved to something pretty nice these days. I find it a lot easier to seperate the frontend and the backend using flash than using html. (html/php mixes too much code and look, and PHP->XML->XSLT->HTML is ridiculous, and buys you very little. The only thing that kindof works is relatively simple templates)
The only thing I don't like about it, is that it doesn't "gracefully degrade", I mean it's still too hard to expose the structure/content/flow like you can with html.
On the other hand, if I try to do everything by the book using standard xhtml/css/js, for the more complicated things I spend ages getting things to look/react right in the different browsers I want to support (IE Mac&Windows>5, Mozilla,
The fact that Flash is completely vector based is also a major asset, now that there's such a wide range of resolutions in use. (everything between 800x600 and 1600x1200 is extremely common - if I create fixed-pixel content for 800x600 I can guarantee you it'll look too small in 1600x1200)
If I compare html and flash on features and general usability, I'd score both almost evenly: they both have things going for them. As long as I need to create simple information based sites, I use html. The minute I need to make something more complicated like a "web app" I use Flash.
I would define myself as an advanced user, and am using win2k and linux on a daily basis. Because I'm almost running Linux full time, I haven't really felt the need to upgrade to XP, which probably accounts for my unfamilliarity with the new "Luna" UI.
But seeing this almost makes me want to puke. Even though I've been using computers for decades, I wouldn't know where to begin in this UI. There seems to be redundancy all over the place, modes galore, and they seem to show/hide certain tasks/apps/files/settings/menu options completely at random.
I have to admit, maybe if I used it I would like it a bit better. But if I feel "overwhelmed" just by looking at one of the screenshots, how should a newbie user feel. (I seem to remember that when doing usability testing, they ask the subject to first look at the screen without touching anything, and then ask them what they think everything is for)
In contrast, Gnome2 seems to be moving in the right direction by simplifying ("make the simple things easy, the hard ones possible") and unifying as much as possible.
Same thing with MacOS: while the first releases of MacOSX were a step back in usability, they've been repairing the damage with the latest release. At the same time it's a good example of how unification really should work (see the iChat, iSync, iCal, Addressbook, Mail, iTunes integration)
Longhorn and XP seem to like confusion: let's do everything in all the ways everyone in the world might want, and stuff it in one interface. And let's do it all at thesame time too.
the Horror!
Why is everyone referring to the FSF?
This is the Free Standards Group (FSG), not the Free Software Foundation (FSF).
This is about standardizing things across distributions, and setting up a set of useful guidelines that have been well thought through.
Some things I think need researching:
- A bunch of wrappers aimed at making it easy to write GUIs for services (activation, status, description), hardware/network/... configuration, etc etc. A bit like standardizing the backends of the ex-Ximian Setup Tools.
- A decent set of guidelines to handle virtual hosts on servers + wrappers for their configuration/administration.
- moving beyond the fhs: new filesystems and kernel changes introduced will allow a whole bunch of new functionality. I'd like to see some discussion starting about how we can leverage the advantages of union mounts ( "/" vs "/usr": really still needed?), extended attributes and ACL's, LVM etc.
I'd also very much like a comparison with completely different filesystem layouts like MacOSX. I realize that the FHS came to be for very good reasons, but I'm hoping that since we'll have all these features available to us we'll be able to simplify the structure alot without giving up any of the advantages. It's not always nice to be stuck in a lowest common deminator legacy world.
Well, If going with arm means getting these feeble battery-lives that ipaq's and zaurus are getting, then please, no!
True, dragonball is slow - but battery-life is far more important to me than performance. I know I don't put my palm in the cradle every day.
Capacity increases very quickly. That's nice. But what I really care about is performance keeping pace.
I mean, the actual transfer rate with which one can get (ever more) data on or off the disks is increasing very slowly.
The ratio of speed vs capacity is getting worse and worse.
I'd much prefer less capacity and much better performance. Yes, I know I could go RAID0, but that means twice the noise, power consumption, and risk to reliability. Maybe they should have something like raid0-in-a-drive?
Well, you got scammed - you didn't need to go back to VGA. if you got a DVI-I plug and a DVI-D plug, You can use a DVI-I or DVI-D to connect the two digitally.
Check out this passage from a DVI faq:
"
If you have plugs that are DVI-D, they will accept a DVI-D or DVI-I cable. If you have plugs that are DVI-A, they will accept a DVI-A or DVI-I cable. If you have plugs that are DVI-I, they will accept any type of DVI cable.
If you have mistmatched plugs, such as DVI-D and DVI-I or DVI-A and DVI-I, you may use either a DVI-I cable or the cable that matches the other plug. For example, you may use a DVI-D cable on a DVI-I to DVI-D connection, but not a DVI-A cable.
Note: You may not mismatch a DVI-D and a DVI-A connection.
"
There.
Well what are you comparing? Raid0 versus Raid5?
You've got to be kidding! there's a good deal of overhead involved with RAID5.
You're comparing apples and elephants.
As I understand it, with the current system patent examiners have the task to find out whether or not a patent application is truly new/innovative/...
This implies that if you take the path of least resistance (underfunded patent examiners/time constraints/whatever/...) by default, the patent will pass, and a monopoly on the device (albeit temporary) is given out. Effort has to be made to stop a patent application.
Isn't this placing the "burden of proof" at the wrong side? Shouldn't it be so, that by default the patent should NOT be given out?
I've heard (don't know if this is correct) that with the USPTO the patent examiners get rewarded for every patent granted. Shouldn't the patent examiners get a reward for every patent application blocked?
wasn't there a slashdot story at one point where content providers in Norway (not sure) wanted to band together and demand a percentage of what ISP made, because "they were the reason people got on the internet".
Now it's the other way around - "we provide you with customers, so give us some money"
Very funny.
I've been pondering about maybe replacing the DNS system outright.
Something that is distributed, and based on a kind of certification that the users give. Something that would of course have to be attack-resistent (in the sense that a single entity or small group can't profoundly influence the certification of a name->ip mapping on it's own)
The major problem I see, aside from the obvious difficulties in implementing and deploying such a system, is in organising the namespace. Can a name be owned by more than one entity?
You could imagine a system where names would have a subjective meaning, depending on what you and your 'friends' have certified. Other people could get a different entity for the same name.
Needless to say this subjective view is more than just annoying if you think about email for instance. You don't know if a name will lead you to a specific entity. All you're sure of is that the people you trust have picked this one.
Enforcing the one name-one entity mapping could however lead to problems like we currently have:
- first come, first served is a good rule, but gives opportunities to cybersquatters. Conflicting trademarks need to be worked out. Big corp with a trademark practically always wins over an well-intentioned individual. Inevitably disputes follow, courts get involved, lawmakers get involved, everything gets messy and too expensive for individuals, so individuals drop out.
- we could have a global certification where the majority of votes wins. But that leaves little protection for unpopular entities (ie tyranny of the majority).
I'm using vtun.sourceforge.net (which is still under active development) combined with the universal tun/tap driver in the kernel and the linux bridging code to create a more generic solution.
On both sides I create bridges which enslave a physical nic, and the "virtual" tap device.
Since this is an ethernet, not an IP tunnel, it tunnels appletalk, and should tunnel IPX and other traffic too.
It can be compressed and (of course) encrypted too. Performance is very good, even for multiple tunnel, and can be tweaked according to the processor power available.
This way I have even bridged more than two geographical locations too. For instance with 3 connections 1,2,3 I had connections between 1-2, 2-3 and 3-1. But because of the bridging code Spanning Tree Protocol, those redundant connections will only buy you "backup" connections, there's still going to be two nodes that have to communicate via a third. (If you use vtun to do IP tunneling instead of ethernet tunneling, you can use proper routing of course.)
I'm very happy with vtun, it's easy and extremely versatile.
Can someone explain me why they didn't go with the Linux kernel?
Is there a specific performance/design/... issue that is unsurmountable with Linux?
You better have a bloody good reason to redo the kernel, when you could for instance use the time to create a really good user interface or something.
Time is always limited. For everyone.
What I do, is:
- I set up a personal imap server. Fetchmail is also running on that box.
- I use evolution to sync my calendar/contacts/etc
- I can use both evo and mozmail to check out my imap mailbox
- I use programs like mailsync to synchronize my palm straight with the imap server.
sorry for this rant, but:
"Blame the companies who tell the programmers what to do"
Bah. Since you're working for the company, you _are_ in effect part of the company, and share some responsability for its actions.
I wish people would try to be more consistent in their behaviour, and put their money where their mouth is. There's loads of jobs out there especially in the IT sector, even in these post-dot-com times, and I'm sure some of them don't conflict with your personal sense of ethics. Yes, they might pay a little bit less.
A soldier killing someone shares at least a part of the responsability with the chain of command that ordered the killing. People seem to find it easy to hide behind duty/a nation (just look at what happened in WWII), or more appropriate for these times, behind their company.
An oath like this is supposed to work a bit like a union - it forces everyone to be ethical, and would make sure "evil" companies can only find ethical coders (damn!). The fact that this isn't practical IRL doesn't mean you should just be unethical.
Ethical behaviour is doing the right thing, even if it does NOT yield thesame financial benefits/power/geek toys/whatever/... If you're just "ethical" when it's convenient, well...
It seems it's quite popular to say Flash is eeeeviiil, but I'd like to make a case for it:
- You can make a site that's very small, and still looks good (80kb)
- You're sure of how it will look at the user's side. Fonts for instance are embedded in the format.
- The format is as open as for instance pdf (check www.openswf.org) and there's lots of open source libraries and tools that use it.
- You can make it so it's scalable - so it adapts to the size of your browser window. This is important to me, because I can't count the number of times I cursed when I'm viewin html websites on my high-res monitor because they used fixed font-sizes in their css.
Yes, it's true that there's alot of crap sites out there made in Flash. I get the willies everytime I see an "intro". But there certainly also are a lot of crap HTML sites.
Using jpegs or gifs that are 100kb to begin with, or that just cram so much text in a view that you don't know where to start looking, and you get a headache to begin with.
At least with Flash you don't have to deal with slight differences in rendering CSS boxes between internet explorer 5.0 and 5.0 SP2 or whatever. (Even mozilla has it's share of anomalies)
Even if you do your entire html site "by the book" , spec-compliant, clean, etc, you can't avoid encountering bugs between the different implementations.
The only reason _NOT_ to use flash, is because there's no adequate Flash editor for Linux, (or for that matter, an adequare vector drawing program for linux either) - it's the only reason I still need to dual-boot. I'll try wine+flash soon - hoping it's usable.
What makes a good website? Well, it all depends on the actual information you have to offer. If people can find something interesting on your site, and the UI of your site doesn't get in the way, or even, does actually _help_ the visitor to find what they're looking for, then you succeeded.
IIRC, there is a way to sign packages, and there's also a way to do all the questions up front with debconf (apt-utils? not sure) - debconf also has a noninteractive mode, but i don't know if that's any good, never tried it.
You're right about the logging. I disagree about the previous versions of packages, i sometimes have four previous packages in apt's cache. Do you apt-get clean every time you upgrade?
Actually, compression has artifacts, but they're different than "line noise". So yes, the quality will be even lower, and if you can hear the line noise in the uncompressed recording, you'll probably will also hear it in the mp3/ogg.
Some other poster mentioned a flash connected to your ide. But if you're adventurous, you can use something like the linuxbios project (http://linuxbios.org) - what they are doing is overwriting your bios using a stripped down version of linux. Then it can boot another linux image from disk, or from the network.
:)
Additional advantage: you get in linux in 3 seconds in some cases
Of course it all depends if your chipset supports it, and if you're willing to risk it. (of course if you have a flasher, so that you can restore a working bios image it's less of a risk)
I've been looking to do this too;
i rd a.htm
I find the prices for these things a bit too steep. So i set out to make one, but i hit the problem when i tried finding these components in local electronics shops.
anyway here's an address:
http://rcswww.urz.tu-dresden.de/~sb831436/irda/
concurrent connection problems? isn't that what JID's are for? Of course you shouldn't all leave them on "JabberIM" or something - the point is that they should be unique
i agree on the keystroke issue in JIM - didn't realise your issue with MSN.
I'd say one of the things that's keeping Berlin back is the boatloads of misinformation that's going around.
First off - berlin isn't _tied_ to Python; Stefan just suggested using it as a simple prototyping tool - Berlin is language independent (everything happens thru Corba) In fact, the server part is mostly written in C++, but there's client apps in lots of languages.
And no; Berlin isn't just another widget set like some other poster suggested. It allows flexibility (so you won't lose your precious "choice"); but if you "theme" something, it happens on the server; _that's_ where policy is defined - in one central place, like it should be (don't get me started on what a bad idea "meta-theming" is - that just suggests a bad design i believe)...
Apps shouldn't have to bother with the gui, let it be done on the side where it's best done (the display server is closest to the hardware - so the work should be done there) Oh; and by the way: it _has_ anti-aliasing, and way more to boot (it's vector based)
Everyone's always moaning about whether or not innovation is possible with free software/open source; This is an excellent example of great innovation in my mind...
The sad thing is no-one seems to understand or care.
I don't think it's intended that way.
Having this extra layer, allows them to adopt a radically different hardware-architecture for their next-gen product, without having to worry about breaking compatibility, since that layer takes care of that.
You can try to do that in hardware, but you'd end up with the systems amd and intel are using (breaking x86 ops up in smaller ones), and that costs you a significant amount of die space.
I suppose it would be possible to make something native for the crusoe. Problem is it would probably be compatible with this version only!
Don't focus on the situation as it is now. Try to look at it as a "process", an evolution.
I think with the setup they currently have, they'll be able to design new chips that remain x86 compatible and make improvement, at a faster rate than their competition. The people that design the software can ask the hardware guys for specific features that would make emulation faster, and the software guys can make very specific optimizations to that specific fixed hardware - they don't have to worry about the common-denominator problem (what happens with the speed on amd's if i optimize for intel and vice-versa)
I think it definately has a future. Some people might think they're off to a slow start (i'm definately not one of these people - having an emulator perform this good is not an easy feat i believe) but i think they will have the possibility to include improvements and innovations faster than the traditional chipmakers. (unlike for instance intel that has to design a core and live with it for over 5 years).
At least that's what i think...
small typo:
..."
For instance, a color picker might be almost unnecessary on a palm, and I can't think of better use of a 3d environment than mapping a 2D ui on a texture and displaying it in 3D. As i said it's up to the server (or one of its plugins)
should be "...
for instance, a color picker might be almost unnecessary on a palm, and should be replaced on the server by something simpler, and I CAN think of better use of a 3d environment than mapping a 2D ui on a texture and displaying it in 3D.
There are a lot of misconceptions about Berlin.
First, one should realize that it overlaps with more than just the X server.
Berlin is different in that, unlike X, it doesn't communicate between client-app and the server by pushing pixels around. It's the responsability of the server to create a decent (looking) ui, based on the calls the app makes. The fact that those calls are made using CORBA, means they're network, and language independent (perl anyone?).
Using corba shouldn't be scary, in fact, Berlin is much lighter on bandwith in the case of remote display.
A Berlin app can choose the level of abstraction it needs... Some apps might choose/need to draw low level primitives, while others would want to be able to position widgets themselves, while even others just don't need/want to occupy themselves with how something might look, and just tell the server a specific "task", and let it handle it. If you want to get even higher than that, you should take a look here:
http://www.bucksch.com/1/projects/berlin/OOUI/
Why all these levels? Well, the higher level you go, the more freedom you give the server to implement a certain function in a particular way. For instance, a color picker might be almost unnecessary on a palm, and I can't think of better use of a 3d environment than mapping a 2D ui on a texture and displaying it in 3D. As i said it's up to the server (or one of its plugins)
Portability to totally different platforms doesn't always make sense; for instance, it wouldn't make sense to try to force 3d apps/models/vertices and the like in a palm; So if an app wants to use 3d models, it has to create them using a lower level 3d "kit" (which is just another server plugin). That way, the app writer can choose the trade-off.
Other things that I find important are: the resolution-independence (why are >1600x1200 or 640x480 displays almost unusable without heavy adjustments?); the fact that the policy is defined on the server (am i the only one that thinks "meta-theming" - making theme "packages" for different toolkits that go together - is a kludge)
Where does Gtk+ come in? Right now, Berlin sits on top of lower level graphic libraries (libart+ggi, opengl, others are possible). recently it's been possible to use GGI inside Berlin too... so that makes it: GGI on Berlin, on GGI on FB/X/glide/whatever (btw libGGI 2.0 will be out soon). Knowing this there would be 2 different ways of porting GTK+:
1) port GTK+ to GGI - additional benefits are that you get a whole lot of GGI "targets" gtk+ would work on. From what i hear GDK is pretty easy to port.
2) intercept the gtk widget creation calls and map them to the Berlin widgetkit. Advantage: gtk apps would blend in pretty well with real berlin apps, and have all berlin's advantages of being higher level and pixel independent. Disadvantage: i would think it would be _alot_ harder to do.
I guess the difference between the two is a bit (tiny bit) similar to the difference between Wine (api reimplementation) and running plex86 to run windows itself.
Now if Berlin's so great, why hasn't it taken off yet. Unfortunately, the best doesn't always win. DPS for X isn't there yet (dps.sourceforge.net), despite the fact that it's "proven to be good" by for instance MacOSX. (okay it's not entirely thesame but you get my drift)
A major problem with Berlin is that to explain the advantages, you have to write as much as i did just now. Once you know the advantages, it seems obvious that this is the way to go, but as i said, even the people who are interested don't always understand the advantages about it immediately. That means that few developers actually get into it, meaning slow progress and no critical mass yet.
Otoh, the fact that it has gone on for all these years, even when new good-looking ui tech came out, and that the developers still aren't giving up on it at all, proves that a) they're fools or b) they're onto something.
I definately don't think these people are fools. I believe it's one of the few OSS projects that is actually really innovating.
So... what exactly would you gain by this?
It's not like specific configuration programs will be magically able to work on all configuration files because they are in XML. It doesn't make a lot of difference.
Second point: it doesn't have much to do with the kernel. how many things in etc are really linked to the kernel? and for procfs? Ideally we would have just a elaborate directory structure where each file just has _one value_, and not a whole text to parse. No use putting xml there or you'll get trees (xml) within files in trees (directories), kinda beats the point.
If you like the idea of unifying things that much, look into Gconf and the like.
But my vote is to keep it out of the kernel