Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sat 19 Apr 2014, 18:34
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
Vala and Genie programming
Post new topic   Reply to topic View previous topic :: View next topic
Page 31 of 35 [517 Posts]   Goto page: Previous 1, 2, 3, ..., 29, 30, 31, 32, 33, 34, 35 Next
Author Message
tsura

Joined: 01 Dec 2009
Posts: 3

PostPosted: Tue 02 Feb 2010, 23:29    Post subject:  

DMcCunney wrote:
(And while you're at it, define just what you mean by "security".)


I think Lobster may have security issues with web-based client-side and server-side scripting mixed up with general programming security. That's only an issue for browser-oriented client-side scripting, really (I don't know of anything besides JavaScript that would have this issue).

The client can see the JavaScript code, since it's mostly a client-side thing. If that's what you're thinking, no you won't have that problem with Vala or C. In fact, you probably don't need to worry about it at all, unless you want people to type in a password for something (on the Internet) and you don't have access to the server. You could try using encryption keys in that case.

What do you need security for?
Back to top
View user's profile Send private message 
DMcCunney

Joined: 02 Feb 2009
Posts: 894

PostPosted: Tue 02 Feb 2010, 23:54    Post subject:  

tsura wrote:
DMcCunney wrote:
(And while you're at it, define just what you mean by "security".)

I think Lobster may have security issues with web-based client-side and server-side scripting mixed up with general programming security.

I do too, which is why I asked.

Quote:
That's only an issue for browser-oriented client-side scripting, really (I don't know of anything besides JavaScript that would have this issue).

Microsoft Active-X controls, which are fortunately confined to Internet Explorer under Windows. (Microsoft was pushing VBSript as well back when, but it thankfully remained a client side product, and never gained traction as an alternative to JavaScript on web sites.

Quote:
The client can see the JavaScript code, since it's mostly a client-side thing. If that's what you're thinking, no you won't have that problem with Vala or C. In fact, you probably don't need to worry about it at all, unless you want people to type in a password for something (on the Internet) and you don't have access to the server. You could try using encryption keys in that case.

The usual security problems with compiled languages exploit things like buffer overflow, and are more examples of "how the code is written".
______
Dennis
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4134

PostPosted: Thu 04 Feb 2010, 16:52    Post subject:  

Quote:
Vala Releases

Vala 0.7.10
source tarball

released on February 4, 2010


Changes
Support coalescing operator ??.
Support to_string and bitwise complement with enums.
Return handler id when connecting signal handlers.
Support struct comparison.
Support constructor chaining in structs.
Enforce protected member restrictions.
Improve performance of flow analysis.
Support automatic line continuations in Genie.
Improvements to the .gir reader and writer.
Add --enable-mem-profiler commandline option.
Many bug fixes and binding updates.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
rarsa


Joined: 29 May 2005
Posts: 3053
Location: Kitchener, Ontario, Canada

PostPosted: Sat 06 Feb 2010, 09:37    Post subject:  

Sorry for the late response, I've been quite busy at work.
Lobster wrote:
Hi rarsa Smile Is Vala more secure than C?
Or is it how the code is written?

Someone responded with "Define security". But based on your question it seems to me that you meant "Safety". Quite similar words, used as synonyms in regular English but in coding terms a bit different.

Security basically means: Who has access to what and when. That applies to users as much as the calls and objects passed around inside an application.

Some languages and runtime environments provide Security mechanisms such as code level signing. To the best of my knowledge, neither C or Vala provide that, so it depends on the program itself to determine security.

Safety in this context is the syntax or mechanisms that a language has to protect from having code vulnerabilities. So in a sense depends on the language ONLY if the programmer uses such syntax and mechanisms.

In this sense C is less safe "out of the box" but there are library frameworks that provide the extra safety such as protection against memory overflow.

Vala in a sense is safer C as it implements those safety mechanisms for the programer such as proper type checking.

I haven't used Vala long enough or in programs large enough to find out if it has safety mechanisms that would help prevent for example SQL injections other than using the same libraries as C.

So responding to the question: I think Vala is safer than C mainly because Vala does the work of writing safer C.

Example of Safety lapse
Example of security lapse

_________________
http://rarsa.blogspot.com Covering my eclectic thoughts
http://www.kwlug.org/blog/48 Covering my Linux How-to
Back to top
View user's profile Send private message Visit poster's website 
Lobster
Official Crustacean


Joined: 04 May 2005
Posts: 15117
Location: Paradox Realm

PostPosted: Sat 06 Feb 2010, 12:35    Post subject:  

Quote:
C mainly because Vala does the work of writing safer C.


That makes sense - being forced to write better code.
Many thanks Smile

_________________
Puppy WIKI
Back to top
View user's profile Send private message Visit poster's website 
DMcCunney

Joined: 02 Feb 2009
Posts: 894

PostPosted: Sat 06 Feb 2010, 12:58    Post subject:  

rarsa wrote:
So responding to the question: I think Vala is safer than C mainly because Vala does the work of writing safer C.

Expanding a bit on what Rarsa said, it might help to talk a little about C.

The C language was first created by a programmer named Dennis Ritchie in the 1960s at AT&T's Bell Laboratories. At the time, system software was normally written in assembler. Each line in an assembly language program normally translates to one machine language instruction. This makes it possible to write the smallest, most efficient code, because the programmer can specify exactly what the machine is to do. But it's difficult to write and hard to maintain, because it requires the developer to look at things the way the machine does, which will have little relation to what the program is supposed to do, and assembly language programs may take thousands of lines to do what can be done in a few dozen lines in a higher level language. In addition, assembler lacks the high-level constructs programmers are used to, like IF-THEN-ELSE, DO WHILE, and CASE.

Ritchie based his efforts on an earlier language called BCPL. His goal was a language that would have the high-level constructs available in other languages, be relatively easy to port to different architectures, but be efficient enough that you didn't have to write in assembler to get performance. He wanted a language that could be used for writing things like operating systems.

At the same time Dennis Ritchie was developing C, another group of programmers under Ken Thompson and Brian Kernighan were writing a new OS. They were software developers, and wanted an environment better suited for software development than the one provided by the operating system on the DEC mini-computer they used for development. the new OS was called Unix.

Early versions of Unix were written in Macro-11, the assembly language provided with the DEC system. But around Unix Version 6, C had matured to the point where it could be used, and most of Unix was rewritten in C, with only about 10% dealing directly with the underlying hardware still in assembler.

Because C was relatively portable, it was possible to bring C up on a different machine, and then port Unix to it with a fraction of the effort working in assembler would require. Unix expanded rapidly within Bell Labs, and then throughout AT&T. C became a popular language for writing applications as well as operating systems.

Because C is fairly low-level, it requires care by the programmer writing code. Things handled automatically by other modern languages must be explicitly coded in C.

For example, the biggest problem on any system is probably memory management. When a program runs, it requests memory from the OS to hold its code and the data it will process. When it's finished with the memory, the memory used must be returned to the OS. Some modern languages attempt to handle that for you, with mechanisms like "garbage collection", where memory no longer used is automatically collected and returned to the OS for use by other things. In C, when you are finished with memory, you must explicitly free it.

This requirement leads to one common programming problem - memory leaks. The program will allocate memory for some purpose, but will not explicitly free it, so the OS may think the memory is in use and be unable to reuse it even after the program that asked for it has stopped running. And it can cause programs that are still running to have ever increasing memory requirements until the machine becomes unresponsive or even crashes. (And it's a complex issue, because even if you are careful to explicitly free memory when done with it, it's possible for other problems to cause the program to fail to reach the instruction that is intended to free the allocated memory.)

Another problem affects any language, and can be summarized as "Never trust your data". When you write a program, your program will be dealing with data, and the data will come from elsewhere. Your code will allocate a buffer in memory to hold the data is is processing. What happens if your program allocates a 5K buffer for data, and what it actually gets is 10K? What happens to the extra 5K? It overflows the memory buffer, and winds up overwriting other parts of memory, with bad results. These kinds of problems are known as "buffer overflow" errors. Most of the Critical Security patches released for Windows are intended to patch such problems, as bad guys discover buffer vulnerabilities that will let malicious code destabilize the system and crash it or leave it vulnerable to outside control.

When the code being patched was first written, it simply didn't occur to the programmers that anyone would deliberately try to overflow a buffer in memory for bad purposes. They assumed the data would be in the correct form and amount, and took no measures to handle the case where it wasn't. The problem isn't unique to Windows, either. There are regular patches released to plug such vulnerabilities in Linux code, too.

C isn't really terribly more unsafe than other languages. It's possible to write unsafe code in pretty much any language out there. But C is powerful, so "With great power comes great responsibility". Things other languages do for you you must do for yourself in C, and must be aware you must do them, and do them correctly.

Why not use something else instead of C? It depends on what you are doing. As programming languages become progressively higher level, code written in the becomes progressively larger. Things that are specified in detail by the programmer in a lower level language are handled automatically by the higher-level one, but the code that does it won't be as small and fast as the lower level language can produce. Modern hardware is fast and powerful enough that you usually don't care, and we see "bloat" because it's faster and cheaper to throw more hardware at the code than to go through the efforts needed to make it smaller and faster. Hardware is cheap. Developer time is expensive.

So when you are looking at a development effort, one question will be what to write in, and ideally, you'll use a language intended for the sort of problem you are trying to solve. If you want your code to be cross platform, and able to be built and run on Windows, Mac OS/X, and Linux, you will probably use C or C++ because they are portable. If you are writing a GUI front-end for something that will only ever be used on Windows, Visual BASIC might be the best choice, as it's well suited for that sort of task.

Every language has strengths and weaknesses, and requires developers to know what they are doing to code effectively.
______
Dennis
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4134

PostPosted: Tue 16 Feb 2010, 14:30    Post subject:  

Sorry to interupt the philosophical discussion, but I got another wild idea. This time a faster, lower resource replacement for gktdialog using the new (as of 2.14) builtin gtkbuilder.

Here is an example:

Code:
/*
 * compilation:
 * valac --pkg gtk+-2.0 --pkg gmodule-2.0 sample.vala
 */
using Gtk;
 
public static void on_button1_clicked (Button source) {
    source.label = "Thank you!";
}
 
public static void on_button2_clicked (Button source) {
    source.label = "Thanks!";
}
 
static int main (string[] args) {     
    Gtk.init (ref args);
 
    try {
        var builder = new Builder ();
        builder.add_from_file ("sample.ui");
        builder.connect_signals (null);
        var window = builder.get_object ("window") as Window;
        window.show_all ();
        window.destroy.connect (Gtk.main_quit);
        Gtk.main ();
    } catch (Error e) {
        stderr.printf ("Could not load UI: %s\n", e.message);
        return 1;
    }
 
    return 0;
}


Obvious first questions:
1. need to set it up to have a variable filename (from script/command line)???
2. if variables get changed via the UI can they be accessible from the script that calls it - if so how?

There are plenty of gtkbuilder ui examples - abiword 2.8.X has quite a few

Any ideas? Or is gtkdialog fast enough if we throw enough hardware at it?

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
DMcCunney

Joined: 02 Feb 2009
Posts: 894

PostPosted: Tue 16 Feb 2010, 15:05    Post subject:  

technosaurus wrote:
Obvious first questions:
1. need to set it up to have a variable filename (from script/command line)???
2. if variables get changed via the UI can they be accessible from the script that calls it - if so how?

There are plenty of gtkbuilder ui examples - abiword 2.8.X has quite a few

Any ideas? Or is gtkdialog fast enough if we throw enough hardware at it?

Let me make sure I understand this.

Gtk builder is a Vala builtin. You can use it within Vala code.

But Vala is a compiled language, so your sample code will be executed in the context of compilation, and compilation requires the dev SFS installed.

Are you thinking you might be able to create a compiled Vala executable that will perform the same functions as Gtkdialog, configurable when run from command line parms, but smaller and lighter than Gtkdialog?

Gtkdialog is livable on my Puppy box (857mhz CPU, 256MB RAM, ATI Rage Pro onboard graphics), but a lot of the boxes people are using Puppy on simply don't have the hardware to throw at it.

I might go a different route, install TclTk as a default on Puppy, and use it for the purposes Gtkdialog gets applied to. It's the sort of thing it's designed to do.
______
Dennis
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4134

PostPosted: Tue 16 Feb 2010, 15:58    Post subject:  

Gtkbuilder was added to gtk in 2.14 and has basically made libglade obsolete, so the only vala binding required would be gtk (and apparently gmodule?) Most active gtk software is using it now, so there are plenty of examples.

The .ui (or .xml) files are read in after compilation - much the way .glade files are. Gtkdialog can already load glade files on the fly using libglade - but it is slow & resource hungry.

There are several other programs that do something similar in various (all slow) methods ... gkt-server(builds gui line by line from script), gtkdialog(libglade slows it down), bashdiff(slows down all bash scripts)

As for adding Tcl/Tk, it does work well, its easy and I like it - maybe better than Gtk, but Gtk can't go away completely - I have looked for suitable, light non-Gtk replacements - they are pretty sparse and mostly Qt which is anything but light. A Gtkbuilder executable should only be a few kb (compared to a few MB of Tcl/Tk) and be much faster than the others.

Most glade examples can be converted to gtkbuilder with a converter so I may try converting renaming one of the sample glade files from gtkdialog to sample.ui to test it out using the above code from the valaide examples

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
disciple

Joined: 20 May 2006
Posts: 6378
Location: Auckland, New Zealand

PostPosted: Wed 17 Feb 2010, 01:40    Post subject:  

Technosaurus, it still isn't clear whether you are suggesting writing something like Gtkdialog which uses gtkbuilder instead of glade, or if you are suggesting that it is already possible to do what we do with glade, somehow, or if you are suggesting something else...
_________________
DEATH TO SPREADSHEETS
- - -
Classic Puppy quotes
- - -
Beware the demented serfers!
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2169

PostPosted: Wed 17 Feb 2010, 12:17    Post subject:  

I read it like this:
"writing something like Gtkdialog which uses gtkbuilder instead of glade"
and since there is a program to convert glade to gtkbuilder *.ui format, then existing scripts for gtkdialog would be easier to convert to the new 'language'.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4134

PostPosted: Wed 17 Feb 2010, 15:50    Post subject:  

amigo wrote:
I read it like this:
"writing something like Gtkdialog which uses gtkbuilder instead of glade"
and since there is a program to convert glade to gtkbuilder *.ui format, then existing scripts for gtkdialog would be easier to convert to the new 'language'.


Precisely...

Though after checking with the gtkdialog tips thread, Zigbert had no recollection of any glade based projects - nor do I... Perhaps there is something in the 3.X series since I think the glade builder was part of it.... so that made me think it would be better to patch gtkdialog to replace glade with gtkbuilder - something I don't have the C background to do, but I did find this straightforward explanation of how to port from glade to gtkbuilder http://library.gnome.org/devel/gtk/unstable/gtk-migrating-GtkBuilder.html Disciple has already done something similar with "glipper-lite"

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2169

PostPosted: Wed 17 Feb 2010, 16:22    Post subject:  

Yeah, but that was for compiled code. To convert/re-write gtkdialog, there would probably be some bit of work to do re-working the syntax parser -although the convertor mentioned should outline the necessary changes.
I have my doubts that the resulting program would be significantly faster than gtkdialog though. Most of time it takes to start up is consumed in parsing/interpreting the script(or *.xml file) and then in linking all the libs which are needed. vala/genie may link a little faster than libglade, but that still leaves a very long list of libs which still must be linked at runtime: gtk, glib, atk, cairo, pango. That's what makes ordinary GTK2 programs much slower to start than their gtk1 counterparts -plus the extra time for dynamically-loading icons from STOCK.
But, I don't mean to put a damper on any effort to 'port' gtkdialog to genie. If the functionality could be reliably duplicated and a reliable convertor created for converting Puppy's hude stock of gtkdialog proggies... otherwise, it would probably be a disservice -I mean you already have a split between existing gtkdialog apps which work (or not) based on at least two versios of gtkdialog. introducing a new class of similar, but not directly incompatible, apps would only compund the situation.

Meanwhile, since Puppy relies so heavily on gtkdialog, and startup times can be significant, it would probably help greatly to use a 'pre-linked' version of gtkdialo. that should significantly reduce startup times. It would imply, though, that the program always be re-compiled and re-linked any time any of the pre-linked libs (listed above) are changed. Pre-linking can make a big difference on applications which link in lots of libs.
On my system which uses src2pkg to track dependencies, I have a script which determines the build order of all installed programs. glade consistently comes in last on the list as it requires more pre-installed libs than anything else on my system. (kde apps would probably be worse, but i don't use or build them). The point is that anything that uses libglade can benefit more than nearly anything else from pre-linking.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4134

PostPosted: Wed 17 Feb 2010, 17:30    Post subject:  

I have been meaning to test out the effects of prelinking and LD_PRELOAD anyways... so I'll give that a shot...

to prelink do you just add LDFLAGS=-Wl,-z,now (instead of the default "lazy")...

I'm not certain that libglade is always needed unless using a .glade file... so maybe it would benefit from --as-needed (or is prelinking mutually exclusive to --as-needed?)

I don't think that it would be too easy to properly port all of gtkdialog to vala/genie - it would be easier (for me at least) to learn enough C to patch it to remove the glade requirement and use Gtk's gtkbuilder components instead.

Since so few people have used the glade portion of gtkdialog I doubt that my original idea to have just a gtkbuilder executable has any merit.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
disciple

Joined: 20 May 2006
Posts: 6378
Location: Auckland, New Zealand

PostPosted: Thu 18 Feb 2010, 05:41    Post subject:  

I just built gtkdialog without glade and tested Pburn with it. It didn't seem to startup any faster, and only used 1 MB less memory, but that's enough to be worth it Smile
I don't know whether it would have more effect on a gtkdialog program which uses glade files. But does anyone even know of any gtkdialog programs which use glade files? I don't. So if we really wanted to get rid of glade, we could simply build gtkdialog without it...

_________________
DEATH TO SPREADSHEETS
- - -
Classic Puppy quotes
- - -
Beware the demented serfers!
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 31 of 35 [517 Posts]   Goto page: Previous 1, 2, 3, ..., 29, 30, 31, 32, 33, 34, 35 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1096s ][ Queries: 13 (0.0054s) ][ GZIP on ]