12,938 research outputs found

    Sistema de bloqueio de computadores

    Get PDF
    Mestrado em Engenharia de Computadores e TelemáticaThe use of multiple computing devices per person is increasing more and more. Nowadays is normal that mobile devices like smartphones, tablets and laptops are present in the everyday life of a single person and in many cases people use these devices to perform important operations related with their professional life. This also presents a problem, as these devices come with the user in everyday life and the fact that often they have a high monetary value means that these devices are susceptible to theft. This thesis introduces a computer locking system that distinguishes itself from existing similar systems because (i) it is designed to work independently of the Operating System(s) installed on the laptop or mobile device, (ii) depends on a firrmware driver that implements the lock operation making it resistant to storage device formats or any other attack that uses software operations. It is also explored the operation of a device that has a firrmware that follows the Unified Extensible Firmware Interface (UEFI) specification as well as the development of drivers for this type of firrmware. It was also developed a security protocol and various cryptographic techniques where explored and implemented.O uso de vários dispositivos computacionais por pessoa está a aumentar cada vez mais. Hoje em dia é normal dispositivos móveis como o smartphone, tablet e computador portátil estarem presentes no quotidiano das pessoas e em muitos casos as pessoas necessitam de realizar tarefas na sua vida profissional nestes dispositivos. Isto apresenta também um problema, como estes dispositivos acompanham o utilizador no dia a dia e pelo facto de muitas vezes terem um valor monetário elevado faz com que estes dispositivos sejam suscetíveis a roubos. Esta tese introduz um sistema de bloqueio de computadores que se distingue dos sistemas similares existentes porque, (i) _e desenhado para funcionar independentemente do(s) sistema(s) operativo(s) instalado(s) no computador portátil ou no dispositivo móvel, (ii) depende de um driver do firrmware que concretiza a operação de bloqueio fazendo com que seja resistente contra formatação do dispositivo de armazenamento ou qualquer outro ataque que tenho por base a utilização de software. É explorado então o funcionamento de um dispositivo que tenha um firmware que respeita a especificação Unfied Extensible Firmware Interface (UEFI) assim como a programação de drivers para este tipo de firmware. Foi também desenvolvido um protocolo de segurança e são exploradas várias técnicas criptográficas passiveis de serem implementadas

    Technical Dimensions of Programming Systems

    Get PDF
    Programming requires much more than just writing code in a programming language. It is usually done in the context of a stateful environment, by interacting with a system through a graphical user interface. Yet, this wide space of possibilities lacks a common structure for navigation. Work on programming systems fails to form a coherent body of research, making it hard to improve on past work and advance the state of the art. In computer science, much has been said and done to allow comparison of programming languages, yet no similar theory exists for programming systems; we believe that programming systems deserve a theory too. We present a framework of technical dimensions which capture the underlying characteristics of programming systems and provide a means for conceptualizing and comparing them. We identify technical dimensions by examining past influential programming systems and reviewing their design principles, technical capabilities, and styles of user interaction. Technical dimensions capture characteristics that may be studied, compared and advanced independently. This makes it possible to talk about programming systems in a way that can be shared and constructively debated rather than relying solely on personal impressions. Our framework is derived using a qualitative analysis of past programming systems. We outline two concrete ways of using our framework. First, we show how it can analyze a recently developed novel programming system. Then, we use it to identify an interesting unexplored point in the design space of programming systems. Much research effort focuses on building programming systems that are easier to use, accessible to non-experts, moldable and/or powerful, but such efforts are disconnected. They are informal, guided by the personal vision of their authors and thus are only evaluable and comparable on the basis of individual experience using them. By providing foundations for more systematic research, we can help programming systems researchers to stand, at last, on the shoulders of giants

    Perfect is the enemy of test oracle

    Full text link
    Automation of test oracles is one of the most challenging facets of software testing, but remains comparatively less addressed compared to automated test input generation. Test oracles rely on a ground-truth that can distinguish between the correct and buggy behavior to determine whether a test fails (detects a bug) or passes. What makes the oracle problem challenging and undecidable is the assumption that the ground-truth should know the exact expected, correct, or buggy behavior. However, we argue that one can still build an accurate oracle without knowing the exact correct or buggy behavior, but how these two might differ. This paper presents SEER, a learning-based approach that in the absence of test assertions or other types of oracle, can determine whether a unit test passes or fails on a given method under test (MUT). To build the ground-truth, SEER jointly embeds unit tests and the implementation of MUTs into a unified vector space, in such a way that the neural representation of tests are similar to that of MUTs they pass on them, but dissimilar to MUTs they fail on them. The classifier built on top of this vector representation serves as the oracle to generate "fail" labels, when test inputs detect a bug in MUT or "pass" labels, otherwise. Our extensive experiments on applying SEER to more than 5K unit tests from a diverse set of open-source Java projects show that the produced oracle is (1) effective in predicting the fail or pass labels, achieving an overall accuracy, precision, recall, and F1 measure of 93%, 86%, 94%, and 90%, (2) generalizable, predicting the labels for the unit test of projects that were not in training or validation set with negligible performance drop, and (3) efficient, detecting the existence of bugs in only 6.5 milliseconds on average.Comment: Published in ESEC/FSE 202

    Evaluating the Code Quality of AI-Assisted Code Generation Tools: An Empirical Study on GitHub Copilot, Amazon CodeWhisperer, and ChatGPT

    Full text link
    Context: AI-assisted code generation tools have become increasingly prevalent in software engineering, offering the ability to generate code from natural language prompts or partial code inputs. Notable examples of these tools include GitHub Copilot, Amazon CodeWhisperer, and OpenAI's ChatGPT. Objective: This study aims to compare the performance of these prominent code generation tools in terms of code quality metrics, such as Code Validity, Code Correctness, Code Security, Code Reliability, and Code Maintainability, to identify their strengths and shortcomings. Method: We assess the code generation capabilities of GitHub Copilot, Amazon CodeWhisperer, and ChatGPT using the benchmark HumanEval Dataset. The generated code is then evaluated based on the proposed code quality metrics. Results: Our analysis reveals that the latest versions of ChatGPT, GitHub Copilot, and Amazon CodeWhisperer generate correct code 65.2%, 46.3%, and 31.1% of the time, respectively. In comparison, the newer versions of GitHub CoPilot and Amazon CodeWhisperer showed improvement rates of 18% for GitHub Copilot and 7% for Amazon CodeWhisperer. The average technical debt, considering code smells, was found to be 8.9 minutes for ChatGPT, 9.1 minutes for GitHub Copilot, and 5.6 minutes for Amazon CodeWhisperer. Conclusions: This study highlights the strengths and weaknesses of some of the most popular code generation tools, providing valuable insights for practitioners. By comparing these generators, our results may assist practitioners in selecting the optimal tool for specific tasks, enhancing their decision-making process

    ‘Mental fight’ and ‘seeing & writing’ in Virginia Woolf and William Blake

    Get PDF
    This thesis is the first full-length study to assess the writer and publisher Virginia Woolf’s (1882-1941) responses to the radical Romantic poet-painter, and engraver, William Blake (1757-1827). I trace Woolf’s public and private, overt and subtle references to Blake in fiction, essays, notebooks, diaries, letters and drawings. I have examined volumes in Leonard and Virginia Woolf’s library that are pertinent, directly and indirectly, to Woolf’s understanding of Blake. I focus on Woolf’s key phrases about Blake: ‘Mental fight’, and ‘seeing & writing.’ I consider the other phrases Woolf uses to think about Blake in the context of these two categories. Woolf and Blake are both interested in combining visual and verbal aesthetics (‘seeing & writing’). They are both critical of their respective cultures (‘Mental fight’). Woolf mentions ‘seeing & writing’ in connection to Blake in a 1940 notebook. She engages with Blake’s ‘Mental fight’ in ‘Thoughts on Peace in an Air Raid’ (1940). I map late nineteenth and early twentieth-century opinion on Blake and explore Woolf’s engagement with Blake in these wider contexts. I make use of the circumstantial detail of Woolf’s friendship with the great Blake collector and scholar, Geoffrey Keynes (1887-1982), brother of Bloomsbury economist John Maynard Keynes. Woolf was party to the Blake centenary celebrations courtesy of Geoffrey Keynes’s organisation of the centenary exhibition in London in 1927. Chapter One introduces Woolf’s explicit references to Blake and examines the record of Woolf scholarship that unites Woolf and Blake. To see how her predecessors had responded, Chapter Two examines the nineteenth-century interest in Blake and Woolf’s engagement with key nineteenth-century Blakeans. Chapter Three looks at the modernist, early twentieth-century engagement with Blake, to contextualise Woolf’s position on Blake. Chapter Four assesses how Woolf and Blake use ‘Mental fight’ to oppose warmongering and fascist politics. Chapter Five is about what Woolf and Blake write and think about the country and the city. Chapter Six discusses Woolf’s reading of John Milton (1608-1674) in relation to her interest in Blake, drawing on the evidence of Blake’s intense reading of Milton. Chapter Seven examines further miscellaneous continuities between Woolf and Blake. Chapter Eight proposes, in conclusion, that we can only form an impression of Woolf’s Blake. The thesis also has three appendices. First, a chronology of key publications which chart Blake’s reputation as well as Woolf’s allusions to Blake. Second a list all of Blake’s poetry represented in Woolf’s library including contents page. The third lists all the other volumes in Woolf’s library that proved relevant. Although Woolf’s writing is the subject of this thesis, my project necessitates an attempt to recover how Blake was understood and misunderstood by numerous writers in the early twentieth century. The thesis argues Blake is a model radical Romantic who combines the visual and the verbal and that Woolf sees him as a kindred artist

    Defining Service Level Agreements in Serverless Computing

    Get PDF
    The emergence of serverless computing has brought significant advancements to the delivery of computing resources to cloud users. With the abstraction of infrastructure, ecosystem, and execution environments, users could focus on their code while relying on the cloud provider to manage the abstracted layers. In addition, desirable features such as autoscaling and high availability became a provider’s responsibility and can be adopted by the user\u27s application at no extra overhead. Despite such advancements, significant challenges must be overcome as applications transition from monolithic stand-alone deployments to the ephemeral and stateless microservice model of serverless computing. These challenges pertain to the uniqueness of the conceptual and implementation models of serverless computing. One of the notable challenges is the complexity of defining Service Level Agreements (SLA) for serverless functions. As the serverless model shifts the administration of resources, ecosystem, and execution layers to the provider, users become mere consumers of the provider’s abstracted platform with no insight into its performance. Suboptimal conditions of the abstracted layers are not visible to the end-user who has no means to assess their performance. Thus, SLA in serverless computing must take into consideration the unique abstraction of its model. This work investigates the Service Level Agreement (SLA) modeling of serverless functions\u27 and serverless chains’ executions. We highlight how serverless SLA fundamentally differs from earlier cloud delivery models. We then propose an approach to define SLA for serverless functions by utilizing resource utilization fingerprints for functions\u27 executions and a method to assess if executions adhere to that SLA. We evaluate the approach’s accuracy in detecting SLA violations for a broad range of serverless application categories. Our validation results illustrate a high accuracy in detecting SLA violations resulting from resource contentions and provider’s ecosystem degradations. We conclude by presenting the empirical validation of our proposed approach, which could detect Execution-SLA violations with accuracy up to 99%

    Virtual Robotics in Hybrid Teaching and Learning

    Get PDF
    Traditional robotics instruction in face-to-face classrooms, after-school clubs, and independent competition environments align with expensive, physical robot kits shared by students. Students or parent groups often elect themselves because of previous experience, expertise, or perceived technical ability to dominate the physical robotic platforms’ planning, engineering, building, and subsequent programming. This self-elected grabbing of control leaves students who are not regarded as well-positioned to contribute sidelined to observe the self-appointed experts of the group. Virtual robotics platforms provide educators and coaches with the unique opportunity to give every student access to a robot. Each student learns programming, math, and scientific forces that impact robots through simulated physics algorithms. With their customizable virtual environments, virtual robotics platforms such as Vex VR and Robot Virtual Worlds level the playing field. All students can learn, practice, and subsequently contribute to robotics-centered group projects or competitive teams in meaningful ways. This book chapter delineates the strategies to implement virtual robotics in hybrid classroom environments supported by the Technological Pedagogical Content Knowledge (TPACK) framework. Additionally, this chapter reviews how computer-aided design and augmented reality platforms provide students with the opportunity to incorporate 3D objects into virtual worlds

    How to Be a God

    Get PDF
    When it comes to questions concerning the nature of Reality, Philosophers and Theologians have the answers. Philosophers have the answers that can’t be proven right. Theologians have the answers that can’t be proven wrong. Today’s designers of Massively-Multiplayer Online Role-Playing Games create realities for a living. They can’t spend centuries mulling over the issues: they have to face them head-on. Their practical experiences can indicate which theoretical proposals actually work in practice. That’s today’s designers. Tomorrow’s will have a whole new set of questions to answer. The designers of virtual worlds are the literal gods of those realities. Suppose Artificial Intelligence comes through and allows us to create non-player characters as smart as us. What are our responsibilities as gods? How should we, as gods, conduct ourselves? How should we be gods

    A productive response to legacy system petrification

    Get PDF
    Requirements change. The requirements of a legacy information system change, often in unanticipated ways, and at a more rapid pace than the rate at which the information system itself can be evolved to support them. The capabilities of a legacy system progressively fall further and further behind their evolving requirements, in a degrading process termed petrification. As systems petrify, they deliver diminishing business value, hamper business effectiveness, and drain organisational resources. To address legacy systems, the first challenge is to understand how to shed their resistance to tracking requirements change. The second challenge is to ensure that a newly adaptable system never again petrifies into a change resistant legacy system. This thesis addresses both challenges. The approach outlined herein is underpinned by an agile migration process - termed Productive Migration - that homes in upon the specific causes of petrification within each particular legacy system and provides guidance upon how to address them. That guidance comes in part from a personalised catalogue of petrifying patterns, which capture recurring themes underlying petrification. These steer us to the problems actually present in a given legacy system, and lead us to suitable antidote productive patterns via which we can deal with those problems one by one. To prevent newly adaptable systems from again degrading into legacy systems, we appeal to a follow-on process, termed Productive Evolution, which embraces and keeps pace with change rather than resisting and falling behind it. Productive Evolution teaches us to be vigilant against signs of system petrification and helps us to nip them in the bud. The aim is to nurture systems that remain supportive of the business, that are adaptable in step with ongoing requirements change, and that continue to retain their value as significant business assets
    • …
    corecore