Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #21601 > unrolled thread
| Started by | Ramon F Herrera <ramon@conexus.net> |
|---|---|
| First post | 2013-01-22 06:41 -0800 |
| Last post | 2013-01-27 23:33 -0800 |
| Articles | 20 on this page of 106 — 15 participants |
Back to article view | Back to comp.lang.java.programmer
The Revenge of the Geeks Ramon F Herrera <ramon@conexus.net> - 2013-01-22 06:41 -0800
Re: The Revenge of the Geeks Melzzzzz <mel@zzzzz.com> - 2013-01-22 14:55 +0000
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-22 22:29 -0500
Re: The Revenge of the Geeks Ramon F Herrera <ramon@conexus.net> - 2013-01-22 06:58 -0800
Re: The Revenge of the Geeks joel garry <joel-garry@home.com> - 2013-01-22 08:54 -0800
Re: The Revenge of the Geeks cipher <cipher@nospamforme.org> - 2013-01-23 00:07 +0000
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-22 17:02 -0800
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-22 22:23 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-22 21:30 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-22 22:26 -0500
Re: The Revenge of the Geeks cipher <cipher@nospamforme.org> - 2013-01-24 00:51 +0000
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-23 20:01 -0500
Re: The Revenge of the Geeks cipher <cipher@nospamforme.org> - 2013-01-24 01:10 +0000
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-23 20:20 -0500
Re: The Revenge of the Geeks cipher <cipher@nospamforme.org> - 2013-01-24 12:15 +0000
Re: The Revenge of the Geeks "Ezekiel" <zeke@nosuchemail.com> - 2013-01-24 07:37 -0500
Re: The Revenge of the Geeks lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-01-24 12:55 +0000
Re: The Revenge of the Geeks cipher <cipher@nospamforme.org> - 2013-01-24 14:40 +0000
Re: The Revenge of the Geeks "Ezekiel" <zeke@nosuchemail.com> - 2013-01-24 10:01 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 10:24 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 10:35 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 10:56 -0500
Re: The Revenge of the Geeks Stuart <DerTopper@web.de> - 2013-01-30 23:54 +0100
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-22 22:32 -0500
Re: The Revenge of the Geeks Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-01-22 21:33 -0800
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-23 00:21 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-23 05:25 -0400
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-23 04:35 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-23 20:17 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-23 22:47 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-24 06:03 -0400
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 04:44 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 11:10 -0500
Re: The Revenge of the Geeks lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-01-24 10:49 +0000
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 11:06 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 16:10 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 17:30 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 17:44 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 17:49 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 17:58 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 21:10 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 22:15 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 22:31 -0600
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-24 23:57 -0800
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-25 22:05 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-25 23:31 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-26 07:25 -0400
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 12:40 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-26 21:34 -0400
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 22:06 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 09:12 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 14:47 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 16:23 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 15:24 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-26 21:47 -0400
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 22:11 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 22:54 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-27 07:46 -0400
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 12:47 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-27 19:40 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 21:16 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-29 22:05 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-30 03:22 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-30 20:12 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-31 02:22 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-02-01 20:12 -0500
Re: The Revenge of the Geeks Gene Wirchenko <genew@telus.net> - 2013-02-04 14:09 -0800
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-02-04 18:28 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-02-05 01:57 -0600
Re: The Revenge of the Geeks Gene Wirchenko <genew@telus.net> - 2013-02-05 09:55 -0800
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-27 19:37 -0500
Re: The Revenge of the Geeks lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-01-27 10:38 +0000
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 13:09 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-27 19:47 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-27 19:45 -0500
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-26 07:26 -0400
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 13:22 -0600
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-26 12:57 -0800
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 16:15 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 22:04 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 00:38 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-27 19:35 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 21:04 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 16:34 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 17:04 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-26 22:14 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 01:38 -0600
Re: The Revenge of the Geeks Martin Gregorie <martin@address-in-sig.invalid> - 2013-01-27 13:13 +0000
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-27 13:59 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 22:17 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 23:06 -0600
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-25 22:10 -0500
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-26 00:31 -0600
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-24 19:42 -0800
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-24 23:22 -0600
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-25 00:03 -0800
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-25 02:41 -0600
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-24 19:31 -0400
Re: The Revenge of the Geeks Lew <lewbloch@gmail.com> - 2013-01-24 11:30 -0800
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-23 20:13 -0500
Re: The Revenge of the Geeks Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-24 15:31 -0400
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-24 14:37 -0500
Re: The Revenge of the Geeks Arne Vajhøj <arne@vajhoej.dk> - 2013-01-23 20:09 -0500
Re: The Revenge of the Geeks Roedy Green <see_website@mindprod.com.invalid> - 2013-01-24 04:30 -0800
Re: The Revenge of the Geeks BGB <cr88192@hotmail.com> - 2013-01-25 02:45 -0600
Re: The Revenge of the Geeks Roedy Green <see_website@mindprod.com.invalid> - 2013-01-27 23:33 -0800
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-27 00:38 -0600 |
| Message-ID | <ke2i45$mhf$1@news.albasani.net> |
| In reply to | #21775 |
On 1/26/2013 9:04 PM, Arne Vajhøj wrote: > On 1/26/2013 5:15 PM, BGB wrote: >> On 1/26/2013 2:57 PM, Lew wrote: >>> But you've been around this newsgroup a long, long time and by now you >>> really should have >>> found out some of this for yourself. Java EE is well documented and >>> the tools are free and open >>> source. So if you really had any genuine desire to understand the >>> concepts and goals of the >>> specifications, you'd've done so already. >>> >> >> I never really went anywhere near Java EE though... > > Most Java developers work full time or part time in an EE > environment, but some does not. > > We may have a tendency to forget about that. Please forgive us > for that. > yeah. granted, I am not particularly much of a serious Java developer either. I am more often here occasionally for "interesting" topics, but the majority of the code I write is in other languages. >> I had always thought the relation was between Java SE and EE was more >> like that between, say, "Windows 7 Home" and "Windows 7 Ultimate", IOW: >> there are differences, but they largely do the same things in the same >> way. >> >> then just suddenly realizing that this is not the case, but that they >> are in-fact rather different things. > > The terms SE and EE do give the wrong impression. For almost all > other products SE and EE means same type of product with different > feature set and different price point (SE support up to 4 CPU, do not > support clustering and cost 10 K$ - EE support up to 16 CPU, do support > clustering and cost 100 K$). > > For Java EE is a server centric framework on top of SE that is > general purpose. > yep, fair enough... >>> Java EE is like a high-level language, but for deployment and >>> connection of services. It's one of >>> those things that separates mere programmers from people who can solve >>> problems with software >>> systems. Its goals are deployability, scalability, ops-friendliness, >>> orchestration-ability (sorry :-)), >>> stability, and pragmatic leverage for useful software systems. It >>> encompasses a broad range of tools, >>> such as message queues, persistent storage, server clustering, >>> resource management, orchestration, >>> troubleshooting, and more. >> >> well, but it is also apparently intended for network/internet stuff. > > Web apps can utilize much of this. It is standard with clustering for > web apps and web apps require some support for HTTP, thread pool, > transactions etc.. > yep. >> in contrast to say, writing standalone apps for a desktop PC or an >> Android phone or similar. > > They may need some of those features, but typical not many. > yeah. many don't even necessarily need sockets. >> there is not a single type of programmer, or software, and there are >> many types of software which may have little to do with either business >> or the internet. > > Internet is quite common. But client side can use internet without EE. > it depends some on the app. some categories of apps don't use the internet at all, and many others in only rudimentary ways (like supporting updates), or complete a specific task using application-specific protocols. web-browsers and email clients are a few of the actually internet-requiring apps (as their functionality is tied to the internet), and web-apps basically *are* internet. a question could then become how much of the various types of apps people use: most I use are plain (non-network) desktop apps; then of course, email, usenet, and a browser; main "web-apps" I end up using mostly at this point are Wikipedia, YouTube, Google, and periodically Facebook and online-dating (not that this ever amounts to much...). counting task-bar icons, there are 11 groups of offline apps running, and 3 internet-based apps: Firefox, Winamp, Thunderbird. granted, I often end up with a lot of tabs open in FF, but by no means does life revolve around it. quick survey: most are Wikipedia articles, and some number of other static pages, ... >> like, say, if a person is developing a game on their PC or cell-phone, >> is a lot of this stuff involved? probably not. > > Yep. > >> likewise, even for a small-scale website, it may not matter all that >> much, if all it ever does is mostly serve up static content and files, >> any is typically low-traffic (and, likewise, is served via a home >> internet connection), ... > > Even for a small scale web site the convenience of Tomcat over a > CGI-BIN could justify EE (or PHP or ASP.NET if Java is not a > prerequisite). > could be. I think it is general tradeoffs. at least between C and PHP: PHP is nice so far as it is fairly good at generating web-pages. a C based CGI binary has a slight advantage when it comes to non-HTML content, as it can do a few more advanced tricks, and allows sending pretty much any kind of content (I suspect also streams, but would need to confirm their behavior with more tests, basically to confirm if it is actually streaming the content, as opposed to buffering it). yes, I control my own server, so getting the code compiled for it isn't an issue. ASP.NET exists, but personally I have never used it, so can't say much about it beyond this.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-27 19:35 -0500 |
| Message-ID | <5105c7ec$0$288$14726298@news.sunsite.dk> |
| In reply to | #21791 |
On 1/27/2013 1:38 AM, BGB wrote: > On 1/26/2013 9:04 PM, Arne Vajhøj wrote: >> On 1/26/2013 5:15 PM, BGB wrote: >>> On 1/26/2013 2:57 PM, Lew wrote: >>>> But you've been around this newsgroup a long, long time and by now you >>>> really should have >>>> found out some of this for yourself. Java EE is well documented and >>>> the tools are free and open >>>> source. So if you really had any genuine desire to understand the >>>> concepts and goals of the >>>> specifications, you'd've done so already. >>>> >>> >>> I never really went anywhere near Java EE though... >> >> Most Java developers work full time or part time in an EE >> environment, but some does not. >> >> We may have a tendency to forget about that. Please forgive us >> for that. >> > > yeah. > > granted, I am not particularly much of a serious Java developer either. > I am more often here occasionally for "interesting" topics, but the > majority of the code I write is in other languages. As long as you don't try and shoehorn the different languages into the same paradigm then that should not be a problem. Arne
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-27 21:04 -0600 |
| Message-ID | <ke4q01$eld$1@news.albasani.net> |
| In reply to | #21807 |
On 1/27/2013 6:35 PM, Arne Vajhøj wrote: > On 1/27/2013 1:38 AM, BGB wrote: >> On 1/26/2013 9:04 PM, Arne Vajhøj wrote: >>> On 1/26/2013 5:15 PM, BGB wrote: >>>> On 1/26/2013 2:57 PM, Lew wrote: >>>>> But you've been around this newsgroup a long, long time and by now you >>>>> really should have >>>>> found out some of this for yourself. Java EE is well documented and >>>>> the tools are free and open >>>>> source. So if you really had any genuine desire to understand the >>>>> concepts and goals of the >>>>> specifications, you'd've done so already. >>>>> >>>> >>>> I never really went anywhere near Java EE though... >>> >>> Most Java developers work full time or part time in an EE >>> environment, but some does not. >>> >>> We may have a tendency to forget about that. Please forgive us >>> for that. >>> >> >> yeah. >> >> granted, I am not particularly much of a serious Java developer either. >> I am more often here occasionally for "interesting" topics, but the >> majority of the code I write is in other languages. > > As long as you don't try and shoehorn the different languages > into the same paradigm then that should not be a problem. > yeah. different languages do different things.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-26 16:34 -0500 |
| Message-ID | <51044bde$0$290$14726298@news.sunsite.dk> |
| In reply to | #21745 |
On 1/26/2013 2:22 PM, BGB wrote: > dunno about an app working in a browser, I haven't personally really > looked much into this. the one thing I had noted which I felt might make > this worthwhile was "Google Native Client", but given it is Chrome-only > at this point, this is a drawback (better if Firefox supported it, but > the FF people apparently oppose it). > > Adobe Flash sometimes seemed like a possible option, but isn't > particularly compelling, and the development environment apparently > costs money. Java applet, Flash, SilverLight, Google Native, JavaScript - there are plenty of options. The Adobe GUI development tools cost money. But you can actually develop MXML and AS with any editor/IDE and you can build with ant and the Flex SDK. Arne
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-26 17:04 -0600 |
| Message-ID | <ke1ngi$g80$1@news.albasani.net> |
| In reply to | #21754 |
On 1/26/2013 3:34 PM, Arne Vajhøj wrote: > On 1/26/2013 2:22 PM, BGB wrote: >> dunno about an app working in a browser, I haven't personally really >> looked much into this. the one thing I had noted which I felt might make >> this worthwhile was "Google Native Client", but given it is Chrome-only >> at this point, this is a drawback (better if Firefox supported it, but >> the FF people apparently oppose it). >> >> Adobe Flash sometimes seemed like a possible option, but isn't >> particularly compelling, and the development environment apparently >> costs money. > > Java applet, Flash, SilverLight, Google Native, JavaScript - there > are plenty of options. > yep, not saying that there aren't a lot of options here. the main advantage of Native Client would be that it would be easier for me to target it, mostly because it wouldn't require largely rewriting a bunch of stuff (all the C parts of the project could be kept intact, and compiled fairly directly, ...). but, many of the other options could likely require writing code specifically for them (in contrast to directly porting preexisting code). Silverlight could work, but AFAIK C++/CLI doesn't work with it (sadly, not that it really works great with .NET in general). the main thing here is basically using C++/CLI to compile C code into CIL bytecode, but using C++/CLI tends to reveal apparent ugly issues... but, even as such, it is a little less work IME to port code between C and C# than it is to port code between C and Java. Flash at least theoretically has a C compiler for it (people have shown some of the Quake-series games, namely Quake and Quake 3 Arena, running on Flash before). HTML+JS was fairly limited in the past, but should be more capable now (like with WebGL and similar, ...). I have actually written some small Java applets in the past (very long ago), but nothing more recent. both would (fairly likely) require a fair bit of porting effort (and/or a trans-language compiler). a further limitation in the JS case though is that, given code is sent and recompiled from text form, this puts effective size limits on it (trying to give it a giant mass of trans-compiled code probably wont work very well, and some other areas of JS give a lot of room for doubt). between them, trans-compiling to JVM bytecode would probably work better, but performance is less certain (since pointers and structures need to be simulated, ...). probably going through an intermediate stage could be easier: C -> BSVM bytecode -> JVM bytecode. mostly as, at both stages, things would fit nicer (and the C->BSVM conversion would lift out the vast majority of the pointers, namely by converting most of the pointers to object references, ...). still a lot of hassle though in either scenario. > The Adobe GUI development tools cost money. > > But you can actually develop MXML and AS with any > editor/IDE and you can build with ant and the Flex SDK. > yes, ok. may look into this.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-26 22:14 -0500 |
| Message-ID | <51049ba3$0$293$14726298@news.sunsite.dk> |
| In reply to | #21759 |
On 1/26/2013 6:04 PM, BGB wrote: > On 1/26/2013 3:34 PM, Arne Vajhøj wrote: >> On 1/26/2013 2:22 PM, BGB wrote: >>> dunno about an app working in a browser, I haven't personally really >>> looked much into this. the one thing I had noted which I felt might make >>> this worthwhile was "Google Native Client", but given it is Chrome-only >>> at this point, this is a drawback (better if Firefox supported it, but >>> the FF people apparently oppose it). >>> >>> Adobe Flash sometimes seemed like a possible option, but isn't >>> particularly compelling, and the development environment apparently >>> costs money. >> >> Java applet, Flash, SilverLight, Google Native, JavaScript - there >> are plenty of options. > > yep, not saying that there aren't a lot of options here. > > > the main advantage of Native Client would be that it would be easier for > me to target it, mostly because it wouldn't require largely rewriting a > bunch of stuff (all the C parts of the project could be kept intact, and > compiled fairly directly, ...). Sure about that? I would expect Native Client to block a lot of code for security reasons. > a further limitation in the JS case though is that, given code is sent > and recompiled from text form, this puts effective size limits on it > (trying to give it a giant mass of trans-compiled code probably wont > work very well, and some other areas of JS give a lot of room for doubt). It si common today to develop JS source code with comments, long names, indentation etc. and then strip it before deploying to reduce size. Arne
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-27 01:38 -0600 |
| Message-ID | <ke2ljt$s5s$1@news.albasani.net> |
| In reply to | #21780 |
On 1/26/2013 9:14 PM, Arne Vajhøj wrote: > On 1/26/2013 6:04 PM, BGB wrote: >> On 1/26/2013 3:34 PM, Arne Vajhøj wrote: >>> On 1/26/2013 2:22 PM, BGB wrote: >>>> dunno about an app working in a browser, I haven't personally really >>>> looked much into this. the one thing I had noted which I felt might >>>> make >>>> this worthwhile was "Google Native Client", but given it is Chrome-only >>>> at this point, this is a drawback (better if Firefox supported it, but >>>> the FF people apparently oppose it). >>>> >>>> Adobe Flash sometimes seemed like a possible option, but isn't >>>> particularly compelling, and the development environment apparently >>>> costs money. >>> >>> Java applet, Flash, SilverLight, Google Native, JavaScript - there >>> are plenty of options. >> >> yep, not saying that there aren't a lot of options here. >> >> >> the main advantage of Native Client would be that it would be easier for >> me to target it, mostly because it wouldn't require largely rewriting a >> bunch of stuff (all the C parts of the project could be kept intact, and >> compiled fairly directly, ...). > > Sure about that? > > I would expect Native Client to block a lot of code for > security reasons. > from what I have read, it basically gives a POSIX-like API with OpenGL and a few other things, all running inside of its own sandboxed address space and filesystem. if it supports this much (along with other basic things, like ability to build apps as multiple libraries, ...), most of my stuff should work without too much issue. hopefully at least it is less of a hassle than dealing with the Android NDK, but who knows sometimes?... (what partly killed my efforts on Android was not so much about getting things built, but mostly me not having any good idea how to make my stuff particularly usable via touch-screen UI, vs a mouse+keyboard UI, and not having many good ideas for UIs which would work well absent a mouse+keyboard interface). (a secondary issue mostly had to deal with concern over the often low hardware stats of typical Android devices as compared with a typical modern desktop PC, ...). I did at least get as far as confirming that a lot of my stuff built and worked on ARM-based targets though. one can probably assume it supports most basic things, but I have yet to find a good list of what parts of POSIX it supports. the lists I have found seem to mention including most parts I typically make use of (libdl, pthreads, calls like "mmap()", ...). it was mentioned on the site that it does apparently lack BSD sockets though (annoying, but not a critical loss...). granted, yes, not like code will probably be usable unmodified, but this is sort of to be expected in C land (you usually end up needing a bunch of #ifdef's and globs of target-specific wrapper code anyways). thus far, nothing looks particularly unusual though... >> a further limitation in the JS case though is that, given code is sent >> and recompiled from text form, this puts effective size limits on it >> (trying to give it a giant mass of trans-compiled code probably wont >> work very well, and some other areas of JS give a lot of room for doubt). > > It si common today to develop JS source code with comments, long > names, indentation etc. and then strip it before deploying to > reduce size. > yes, but I mean, say you have a big C codebase, and try to trans-compile to JS. (say, you trans-compile an Mloc-range application to JS and try to get it loaded in the browser). even stripped, it would still be big. the worry is that it could put a strain on the browser getting a large app downloaded and compiled. then again, I guess a proof of concept would be if anyone can get something like Doom 3 trans-compiled to JS and running in a browser.
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2013-01-27 13:13 +0000 |
| Message-ID | <ke394u$jeb$1@localhost.localdomain> |
| In reply to | #21793 |
On Sun, 27 Jan 2013 01:38:24 -0600, BGB wrote: > I did at least get as far as confirming that a lot of my stuff built and > worked on ARM-based targets though. > Slightly OTT coment, but: I can confirm that C ports very easily to ARM within the Linux/gcc environment. My standard CLI editor is MicroEMACS and has been been for years in UNIX, Linux, OS/9 68K and DOS/Windows environments, so when I got a Debian-based RaspberryPi and found its editors were nano and a less- capable vi than I'm used to, of course I ported Microemacs. The only issue I has was that it is termcap-based but the RPi Debian port doesn't support termcap. However, a quick grab for the GNU termcap and Microemacs was up and running. No code changes needed at all[1]. I'm running my RPi in headless mode: if any of you are thinking of doing the same and would like to do the same without needing a direct attached keyboard and screen for the first boot, contact me offline for the gory details. [1] apart from the termcap file: surprisingly, GNU termcap doesn't support the 'tc' attribute but the RedHat termcap does, so I had to edit /etc/termcap to create a monolithic xterm definition for the RPi. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-27 13:59 -0600 |
| Message-ID | <ke410s$npt$1@news.albasani.net> |
| In reply to | #21798 |
On 1/27/2013 7:13 AM, Martin Gregorie wrote: > On Sun, 27 Jan 2013 01:38:24 -0600, BGB wrote: > >> I did at least get as far as confirming that a lot of my stuff built and >> worked on ARM-based targets though. >> > Slightly OTT coment, but: > > I can confirm that C ports very easily to ARM within the Linux/gcc > environment. My standard CLI editor is MicroEMACS and has been been for > years in UNIX, Linux, OS/9 68K and DOS/Windows environments, so when I > got a Debian-based RaspberryPi and found its editors were nano and a less- > capable vi than I'm used to, of course I ported Microemacs. The only > issue I has was that it is termcap-based but the RPi Debian port doesn't > support termcap. However, a quick grab for the GNU termcap and Microemacs > was up and running. No code changes needed at all[1]. > > I'm running my RPi in headless mode: if any of you are thinking of doing > the same and would like to do the same without needing a direct attached > keyboard and screen for the first boot, contact me offline for the gory > details. > > [1] apart from the termcap file: surprisingly, GNU termcap doesn't > support the 'tc' attribute but the RedHat termcap does, so I had to edit > /etc/termcap to create a monolithic xterm definition for the RPi. > yeah. Linux on ARM isn't a big deal to port to. it was initially more scary-seeming, and I am not exactly a huge fan of the Thumb ISA (I prefer x86 IMHO), but in-all, building for ARM wasn't a big deal. (granted, the form I was targeting was running in QEMU, rather than being an RPi). Android is a little more funky, mostly as Google handled their build tools in a very weird way for the NDK (at least at the time, dunno about now, not looked into it more recently). basically, stuff isn't handled like on a more normal Linux, but rather there is lots of APK funkiness, ... NaCl looks interesting, at least so far as it seems to work (still slightly strange in a few ways, but no huge surprise there). less clear is supporting JIT on NaCl. for x86, it would require some tweaking, and for PNaCl, I have little idea. probably not a huge issue though. I still haven't really looked into how NaCl handles access to things like file-resources (still to-be-researched). granted, whether or not all this stuff makes enough sense as an in-browser app to be worthwhile, is yet to be seen.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-24 22:17 -0500 |
| Message-ID | <5101f95f$0$293$14726298@news.sunsite.dk> |
| In reply to | #21686 |
On 1/24/2013 10:10 PM, BGB wrote: > On 1/24/2013 4:58 PM, Arne Vajhøj wrote: >> On 1/24/2013 5:10 PM, BGB wrote: >>> otherwise, not entirely sure why developing for these would be all that >>> much different than dealing with a normal PC or Linux box. >> >> It is not the type of box that makes a difference. >> >> You can run a Java EE app server on your laptop. >> >> You laptop does just not have the IO system and the 24x7 >> reliability to run in most production contexts. >> >> The difference in development is the services provided by the >> server that the application can utilize if the application follows >> the rules. >> > > I have a web-server I am running on an old laptop, it uses Windows XP, > Apache, and also has PHP, MySQL, and MediaWiki... If you decided that you preferred Java over PHP, then you would replace PHP with a Java EE web container (Tomcat would be obvious) and write your web app using Java EE technologies like servlet, JSP and JSF. Arne
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-24 23:06 -0600 |
| Message-ID | <kdt3uj$d0l$1@news.albasani.net> |
| In reply to | #21688 |
On 1/24/2013 9:17 PM, Arne Vajhøj wrote: > On 1/24/2013 10:10 PM, BGB wrote: >> On 1/24/2013 4:58 PM, Arne Vajhøj wrote: >>> On 1/24/2013 5:10 PM, BGB wrote: >>>> otherwise, not entirely sure why developing for these would be all that >>>> much different than dealing with a normal PC or Linux box. >>> >>> It is not the type of box that makes a difference. >>> >>> You can run a Java EE app server on your laptop. >>> >>> You laptop does just not have the IO system and the 24x7 >>> reliability to run in most production contexts. >>> >>> The difference in development is the services provided by the >>> server that the application can utilize if the application follows >>> the rules. >>> >> >> I have a web-server I am running on an old laptop, it uses Windows XP, >> Apache, and also has PHP, MySQL, and MediaWiki... > > If you decided that you preferred Java over PHP, then > you would replace PHP with a Java EE web container (Tomcat > would be obvious) and write your web app using Java EE > technologies like servlet, JSP and JSF. > I use PHP mostly for sake of running MediaWiki, which is probably the biggest/most complicated thing on the site. my own CGI binaries have typically been written in C and compiled into EXE's before being copied over to the server. though, PHP does have the advantage that a person doesn't have to recompile it after editing (though, there is the possibility that a web request could come in with the PHP code in an inconsistent state, say because someone was in the middle of editing the code directly on the server or something...). I had idly considered the possibility of using my own scripting language here, but haven't seen much point. like, C works well enough, and PHP works even if it does look a little funky. I had considered the remote possibility of a kind of "pay and register" thing, which would probably work something like: person clicks button, and does paypal thing; it uses a target URL set to the user registration form; after doing this, it probably gives them their user-key (basically, as a glob of ciphered data), and records this into a file. haven't done so yet, and am currently operating under a "donate if you want to" system, but hardly anyone is making donations, so probably no one would care enough to bother paying and registering either (they would just be like "hay whatever" and not bother, or just warez it or figure out a way to circumvent making a payment or similar via using hacked URLs or something...). so, I haven't done so yet... granted, yes, either way I am not exactly making money here (rarely does anyone donate anything, and in the off chance they do, it has been like $0.05 and similar...). making actually more money on YouTube, as theoretically at least, I have $0.75 on this, from ads on videos, but meh, whatever sometimes...
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-25 22:10 -0500 |
| Message-ID | <5103491a$0$284$14726298@news.sunsite.dk> |
| In reply to | #21693 |
On 1/25/2013 12:06 AM, BGB wrote: > On 1/24/2013 9:17 PM, Arne Vajhøj wrote: >> On 1/24/2013 10:10 PM, BGB wrote: >>> On 1/24/2013 4:58 PM, Arne Vajhøj wrote: >>>> On 1/24/2013 5:10 PM, BGB wrote: >>>>> otherwise, not entirely sure why developing for these would be all >>>>> that >>>>> much different than dealing with a normal PC or Linux box. >>>> >>>> It is not the type of box that makes a difference. >>>> >>>> You can run a Java EE app server on your laptop. >>>> >>>> You laptop does just not have the IO system and the 24x7 >>>> reliability to run in most production contexts. >>>> >>>> The difference in development is the services provided by the >>>> server that the application can utilize if the application follows >>>> the rules. >>>> >>> >>> I have a web-server I am running on an old laptop, it uses Windows XP, >>> Apache, and also has PHP, MySQL, and MediaWiki... >> >> If you decided that you preferred Java over PHP, then >> you would replace PHP with a Java EE web container (Tomcat >> would be obvious) and write your web app using Java EE >> technologies like servlet, JSP and JSF. > > I use PHP mostly for sake of running MediaWiki, which is probably the > biggest/most complicated thing on the site. You could use Java for the same purpose: http://en.wikipedia.org/wiki/JAMWiki > my own CGI binaries have typically been written in C and compiled into > EXE's before being copied over to the server. Servlets that are the part of Java EE which is pure Java code that get executed by HTTP requests. But inlike CGI scripts they get loaded once and kept in memory and run in threads not in separate processes. Arne
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-26 00:31 -0600 |
| Message-ID | <kdvtan$o2d$1@news.albasani.net> |
| In reply to | #21719 |
On 1/25/2013 9:10 PM, Arne Vajhøj wrote: > On 1/25/2013 12:06 AM, BGB wrote: >> On 1/24/2013 9:17 PM, Arne Vajhøj wrote: >>> On 1/24/2013 10:10 PM, BGB wrote: >>>> On 1/24/2013 4:58 PM, Arne Vajhøj wrote: >>>>> On 1/24/2013 5:10 PM, BGB wrote: >>>>>> otherwise, not entirely sure why developing for these would be all >>>>>> that >>>>>> much different than dealing with a normal PC or Linux box. >>>>> >>>>> It is not the type of box that makes a difference. >>>>> >>>>> You can run a Java EE app server on your laptop. >>>>> >>>>> You laptop does just not have the IO system and the 24x7 >>>>> reliability to run in most production contexts. >>>>> >>>>> The difference in development is the services provided by the >>>>> server that the application can utilize if the application follows >>>>> the rules. >>>>> >>>> >>>> I have a web-server I am running on an old laptop, it uses Windows XP, >>>> Apache, and also has PHP, MySQL, and MediaWiki... >>> >>> If you decided that you preferred Java over PHP, then >>> you would replace PHP with a Java EE web container (Tomcat >>> would be obvious) and write your web app using Java EE >>> technologies like servlet, JSP and JSF. >> >> I use PHP mostly for sake of running MediaWiki, which is probably the >> biggest/most complicated thing on the site. > > You could use Java for the same purpose: > > http://en.wikipedia.org/wiki/JAMWiki > interesting... MediaWiki is cool as well, and works well enough, though I ended up ultimately disabling the ability of people to create new user-accounts mostly as a spam-control measure (bots kept coming along and flooding the wiki with spam). I had once considered the idea using a variant of MediaWiki syntax as part of a stand-alone documentation system (sort of like a mix of MediaWiki, Windows Help, and Javadoc), but never really got around to it. the main idea though would be to do it as a single self-contained tool, in contrast to something like MediaWiki which has a list of dependencies needed to make it work (like MySQL and PHP and similar, and assumes using a web-server + browser, ...). but, as noted, I never got to it, and don't currently have any concrete plans for doing so. most of my documentation thus far is either as plain text files, or sometimes as HTML documents. >> my own CGI binaries have typically been written in C and compiled into >> EXE's before being copied over to the server. > > Servlets that are the part of Java EE which is pure Java code that > get executed by HTTP requests. > > But inlike CGI scripts they get loaded once and kept in memory > and run in threads not in separate processes. > yep, could improve performance some I guess. > Arne >
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2013-01-24 19:42 -0800 |
| Message-ID | <7a64bf0c-5341-418b-ba85-0ab2ab523dcb@googlegroups.com> |
| In reply to | #21686 |
BGB wrote: > I didn't mean like CORBA or DCOM, but probably directly copying over > program binaries (DLLs or SOs and precompiled binaries and similar), and > probably using traditional compilation and linking. What does any of that have to do with Java EE, BGB? > Arne Vajhøj wrote: >> Persistent data in the the Java EE world is most often in database. > > well, I meant for code and other resources. WTF? That has nothing to do with Java EE or Java SE. Source code is kept in text files, ideally managed through version control, regardless of which you're using. Or are you talking about the binaries? The binaries are just Java classes. > or, to you mean putting code in the database as well?... > (like, put the JAR in a data-blob and fetch it out via a SELECT or > something?...). Huh? BGB, your posts show no evidence of any comprehension of what Java EE is or does, none for knowledge of what Java EE-compliant products are out there, or the fact that Java EE is just Java with some additional specifications that vendors implement. I suggest you study up on those matters before pontificating about the subject. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-24 23:22 -0600 |
| Message-ID | <kdt4tr$qgv$1@news.albasani.net> |
| In reply to | #21689 |
On 1/24/2013 9:42 PM, Lew wrote: > BGB wrote: >> I didn't mean like CORBA or DCOM, but probably directly copying over >> program binaries (DLLs or SOs and precompiled binaries and similar), and >> probably using traditional compilation and linking. > > What does any of that have to do with Java EE, BGB? > >> Arne Vajhøj wrote: >>> Persistent data in the the Java EE world is most often in database. >> >> well, I meant for code and other resources. > > WTF? > > That has nothing to do with Java EE or Java SE. Source code is kept in text files, > ideally managed through version control, regardless of which you're using. > > Or are you talking about the binaries? The binaries are just Java classes. > >> or, to you mean putting code in the database as well?... >> (like, put the JAR in a data-blob and fetch it out via a SELECT or >> something?...). > > Huh? > > BGB, your posts show no evidence of any comprehension of what Java EE is or does, > none for knowledge of what Java EE-compliant products are out there, or the fact that > Java EE is just Java with some additional specifications that vendors implement. > > I suggest you study up on those matters before pontificating about the subject. > I was not claiming here to have any idea what Java EE was, this much should have been obvious enough... just responding to what people have been writing, but it is confusing, and the Wikipedia article doesn't really make it obvious either. granted, I will not claim to have much familiarity with businesses or enterprise systems either (not a business person, not really worked on anything like this either, ...). or, IOW: this is all in an area I have never gone into, much beyond what was covered in college classes, when trying to study for a CompSci major (and then getting screwed over by stupid math classes and moving...).
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2013-01-25 00:03 -0800 |
| Message-ID | <4ae6f047-5938-4b41-ac9e-25b109612692@googlegroups.com> |
| In reply to | #21694 |
BGB wrote: > Lew wrote: >> BGB, your posts show no evidence of any comprehension of what Java EE is or does, >> none for knowledge of what Java EE-compliant products are out there, or the fact that >> Java EE is just Java with some additional specifications that vendors implement. > >> I suggest you study up on those matters before pontificating about the subject. > > I was not claiming here to have any idea what Java EE was, this much > should have been obvious enough... No, it was not obvious that you were disclaiming knowledge, though it was obvious that you lacked it. Most of the stuff you've been saying about Java EE is very far off the mark. You should read about it. > just responding to what people have been writing, but it is confusing, > and the Wikipedia article doesn't really make it obvious either. I have not heard of anyone being able to program Java from reading a Wikipedia article about it. > granted, I will not claim to have much familiarity with businesses or > enterprise systems either (not a business person, not really worked on > anything like this either, ...). That has nothing to do with being able to evaluate the technical aspects of the specification. > or, IOW: this is all in an area I have never gone into, much beyond what > was covered in college classes, when trying to study for a CompSci major > (and then getting screwed over by stupid math classes and moving...). Exactly. It is an area you have never gone into. I am suggesting that you remedy that. College is irrelevant. "Stupid math classes" are irrelevant. None of that stopped you from talking about Java EE without understanding. You can gain understanding with a modicum of research. You need not blame your history, or your college professor, or past grievances, nor be held back by them. You can determine your own future by doing the freaking research and learning something of what you're passing judgment about. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2013-01-25 02:41 -0600 |
| Message-ID | <kdtgih$3mn$1@news.albasani.net> |
| In reply to | #21696 |
On 1/25/2013 2:03 AM, Lew wrote: > BGB wrote: >> Lew wrote: >>> BGB, your posts show no evidence of any comprehension of what Java EE is or does, >>> none for knowledge of what Java EE-compliant products are out there, or the fact that >>> Java EE is just Java with some additional specifications that vendors implement. >> >>> I suggest you study up on those matters before pontificating about the subject. >> >> I was not claiming here to have any idea what Java EE was, this much >> should have been obvious enough... > > No, it was not obvious that you were disclaiming knowledge, though it was obvious that > you lacked it. > I had thought I had made it more obvious, oh well... > Most of the stuff you've been saying about Java EE is very far off the mark. You should read > about it. > I wasn't saying much about Java EE, only what areas I am familiar with, which go as far as: general software development stuff; games (primarily FPS / First Person Shooters); running a web-server using Apache; some (limited) Java development, namely on desktop PCs, and some on Android; ... most other information was then extrapolated from this, and what I could gather by information online. the idea being that, then people could point out how it works. >> just responding to what people have been writing, but it is confusing, >> and the Wikipedia article doesn't really make it obvious either. > > I have not heard of anyone being able to program Java from reading a Wikipedia article > about it. > on most other topics though, one can at least get a good idea what the thing is from reading an article about it. then one can know where to look for more information. in this case, the article lists off a bunch of stuff, like packages, but doesn't really give a clear understanding of what it is or what it does. >> granted, I will not claim to have much familiarity with businesses or >> enterprise systems either (not a business person, not really worked on >> anything like this either, ...). > > That has nothing to do with being able to evaluate the technical aspects of the > specification. > business people would probably know better what business systems do though, vs someone with no real experience with business stuff. like, for business people doing business stuff or similar, since they do it, they probably know how it works. >> or, IOW: this is all in an area I have never gone into, much beyond what >> was covered in college classes, when trying to study for a CompSci major >> (and then getting screwed over by stupid math classes and moving...). > > Exactly. It is an area you have never gone into. I am suggesting that you remedy that. > > College is irrelevant. "Stupid math classes" are irrelevant. None of that stopped you from > talking about Java EE without understanding. You can gain understanding with a modicum > of research. You need not blame your history, or your college professor, or past > grievances, nor be held back by them. You can determine your own future by doing the > freaking research and learning something of what you're passing judgment about. > I wasn't passing judgement about it, if I were, I would have been saying some thing like "this is stupid, why would anyone use it?" or something. that was not my intent, more stating what I thought, in the hope that people would help clarify just what exactly this thing is. but, me writing about stuff is not what is regrettable here, only that it wasn't more obvious that there is apparently such a communication problem. normally talking about (or going and doing) new/unfamiliar things can be considered a learning experience, but granted, confusion isn't really a good thing. knowledge isn't normally a prerequisite for taking action, but more like something a person can learn along the way, like from experiences and similar. or such...
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-01-24 19:31 -0400 |
| Message-ID | <evjMs.58963$1l4.9593@newsfe29.iad> |
| In reply to | #21671 |
On 01/24/2013 06:10 PM, BGB wrote: [ SNIP ] > > errm, so you can't just copy all the files over to ones' servers? and/or > recompile the code for ones' servers?... > > granted, dunno much about business systems, but I was under the > understanding that most were some combination of: > > rack mounts running Linux, typically with x86 CPUs, and with Gigabit > Ethernet or 10GbE or similar linking them all together. > > one or more server computers in a desktop-like form factor, sometimes > with multi-CPU boards, Xeon or Opteron chips, and craploads of RAM > installed, and sometimes also in a LAN. AFAIK, Linux is also popular > here. (though I guess Windows XP, Windows Vista, and Windows Server, > also make an appearance). > > something more strange, like IBM mainframes or similar, where everyone > uses them via funky multi colored textual interfaces inside of a > terminal emulator, ... pretty much everything I have read about them > sounds strange. > > as for data sharing (between lots of networked servers), I am less sure, > I would think maybe something like NFS or SAMBA, but then thinking of > it, NFS or Samba might not scale well if the number of servers becomes > sufficiently large (like, people would probably want to locally cache > files, rather than always doing IO over the network, ...). > > I guess alternatively, an option could be a sort of centralized > batch-push or batch-pull, where a daemon or similar is used to update > all the servers, or something... (say, on a schedule, they pull from a > Git or Hg repository or something...). > > but, in any case, people have probably figured out all this stuff already. > > otherwise, not entirely sure why developing for these would be all that > much different than dealing with a normal PC or Linux box. > "Server" - sometimes the actual computer/OS (real or virtual) running the "serving" application(s), sometimes the "serving" applications, sometimes the combination, sometimes a cluster of one or more of the above etc - is a role, not a technical specification. A "server" performs a function for client applications, that's basically all there is to it. What particular hardware/OS/application software configurations are the right ones depends entirely on performance requirements, reliability and necessary quality of service etc. These days you can have pretty sizeable user bases served off a consumer tower or laptop, granted best running a "server"-variant OS, and this is often acceptable. A consumer-level computer these days blows away servers of not so long ago, so the kinds of things you mention above aren't what define "server" - it's the function, not the form. As to the technical, these days we're moving away from direct access to physical servers and storage, it's all VMs and private/public clouds. If you're administering VMs you'll certainly be aware where your physical CPUs/cores are, and what real devices have your storage, but everything gets pooled and divvied up from there. AHS
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2013-01-24 11:30 -0800 |
| Message-ID | <57314aab-e4dd-408b-9b13-213e1842c624@googlegroups.com> |
| In reply to | #21631 |
BGB wrote: > Arne Vajh�j wrote: >> BGB wrote: >>> Arved Sandstrom wrote: >>>> BGB wrote: ... [Arved] >>>> So I would disagree with both you and Kevin that "streamlining" the core >>>> language is all that important. You can't do enough of it to core Java >>>> to make it worthwhile, without major changes. So why bother now? What's >>>> important actually *are* those "high cost, high complexity EE >>>> libraries", plus the later SE/EE-agnostic libraries like concurrency. > >>> yes, but the lack of polish for the core language doesn't really make Facts not in evidence. >>> using Java a particularly attractive option when contrasted against, >>> say, C++ or C#. > >> I don't think Java should worry about C++. For business apps, then >> C++ is not really an option. And business apps is what Java is good >> at. > > some of us never go anywhere near business apps though... And therefore don't use Java, if they don't choose. Doesn't say anything against Java as a platform. > ... [Arved] >>>> 90% of developer productivity is achieved by adept and informed use of >>>> what other people have written: libraries. > >>> potentially, but if a person can choose freely, all the major language >>> options have libraries. not necessarily all the same libraries, but >>> libraries none-the-less [sic] ... All automobiles have engines. Why would anyone ever buy a Ferrari? Java is notable for the extent and quality of the libraries bundled with the platform. >> Maybe in the SE space, but not in the EE space. And as Arne points out, the quality of the EE libraries are what make it such a solid spec. > AFAIK, Java EE costs money though, and I somehow suspect probably most Wha...? JBoss, OpenEJB, Glassfish, Geronimo, ... > end-users have Java SE installed. Wha...? Do most end users have C++ installed? > but, in any case, with the other languages there are a wide range of > libraries available, many under fairly open licenses (like MIT or BSD), Are these enterprise libraries suitable for the use cases that make Java dominate? > and there is a lot more GPL stuff available, although GPL has some of Apache, BSD, etc., etc., etc. Including those free Java EE systems that go farther than you know. > its own issues (can't really use GPL'ed code in developing proprietary > software, ...). Which is why other licenses exist. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-23 20:13 -0500 |
| Message-ID | <51008aa5$0$294$14726298@news.sunsite.dk> |
| In reply to | #21614 |
On 1/23/2013 4:25 AM, Arved Sandstrom wrote: > On 01/23/2013 02:21 AM, BGB wrote: >> On 1/22/2013 11:33 PM, Kevin McMurtrie wrote: >>> In article >>> Yes, it is a shame that Oracle runs Java but Sun wasn't so great at it >>> either. Both pushed for high cost, high complexity "enterprise edition" >>> libraries that come and go like fashion but dragged their feet on >>> streamlining the language itself. >> >> much agreed... >> >> the lack of "streamlining" of the core language is admittedly one of my >> bigger complaints about Java at present. >> >> this is along with what few new features are added to the core language >> (and to the JVM) are IMO far too often via ugly hacks. > > I'm not too worried about Java the language being close to stagnant, so > long as library development is up to par. Because if the solution I've > selected includes the JVM, then often Scala or Clojure are better > choices for high-productivity coding. Myself I don't care if Java the > language ever gets updated again - it's not important. The innovation > shifted away from Java the language years ago; there are better JVM > options now. I am a bit skeptical about that as a general approach. If the situation were that Java programs were almost always correct but that what took time was writing all the boilerplate code, then switching to Scala would be an obvious choice. But I don't see that. I see a large portion of Java developers not mastering Java and switching them to Scala would be one big fucking disaster. > So I would disagree with both you and Kevin that "streamlining" the core > language is all that important. You can't do enough of it to core Java > to make it worthwhile, without major changes. So why bother now? What's > important actually *are* those "high cost, high complexity EE > libraries", plus the later SE/EE-agnostic libraries like concurrency. > > 90% of developer productivity is achieved by adept and informed use of > what other people have written: libraries. I completely agree. Arne
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web